It'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)`
It'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...
@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 😅