ipsquiggleIt's interesting: these two function call styles are effectively identical, but for some reason the second one feels almost infinitely more flexible and aesthetic to me:
`inst.MoveTo(x, y)`
`MoveTo(inst, x, y)`
Even if you have to namespace it, I still prefer the second:
`Entity.MoveTo(inst, x, y)`
I think I just really don't like objects hahah...
Josh Grams@ipsquiggle I'm not a huge fan of objects but I've become a big fan of the object notation because putting one argument ahead of and outside the parentheses allows you to chain invocations and have them read forward rather than in reverse, and without nesting parentheses:
inst.MoveTo(x, y).Face(north).Paint(purple)
Paint(Face(MoveTo(inst, x, y), north), purple)
You can certainly get used to the latter but it's one more pain point that causes errors (especially for beginners), like in math having a sign flip or an extra factor of two to account for.
@JoshGrams Ah yes, this style certainly is nice and the nested style is gnarly! I think you could make fancy things to work that way, like
`With(inst).MoveTo(x, y).Etc... `
But you're right you get that for free with objects.
On the other hand....
I've used fluent interfaces for UI numerous times and nesting and grouping is an unholy disaster, breaking it up into procedural function calls is actually a big win IMO. I still use fluent style a lot but the shine is fully off for UI hahaha 😅
@ipsquiggle Oh, yeah, UI is a whole different story; I prefer that to be in data rather than code whenever possible. The immediate mode GUI idiots have a lot to answer for (even though the libraries they were reacting against *were* a problem in the other direction).
@JoshGrams It turns out programming is hard 🤣
@ipsquiggle Good API design is such a lost art
RigearSolution: Support both paths! Since it is hard anyways, why not make it harder! 😁