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! 😁
Matt Hogan 
@ipsquiggle one of the things I like about nim as a language is that the `inst.MoveTo(x,y)` syntax is merely syntax sugar for the function `MoveTo(inst, x, y)`. You get both styles for free.
There's other parts of nim I'm less fond of, but I quite like that part!
@mtthgn
Likewise with Lua's dot-vs-colon calling, both for free.
I do think that even just the presence of "method style" seduces people into creating classes though haha...
Jakub Neruda@ipsquiggle I prefer subject-verb-object syntax. Reads more like a sentence. One has to do more work to make the second syntax more legible:
MoveEntityToLocation(entity, x, y)
MoveEntityToLocation(entity, x, y)
@jakub_neruda True enough. I think of Smalltalk and its style of naming functions and parameters in an extremely verbal style. Its certainly has its own nice aesthetic.
As I've programmed more though, "grammatical" notions have become much less important to me than things like module design and function expressiveness. I can happily use a Lisp if it makes solving my problem easier.
@ipsquiggle I would argue (in the name of Clean code), that the verbosity has more utility than just being aesthetic.
"Function name shall imply the number and order of parameters". MoveEntityToLocation tells you that the function has two logical parameters - entity and location, in this order. Might sound dumb given how good Intellisense is these days, but then you suddenly need to use a function where multiple parameters have the same type, or Intellisense lags or doesn't show up, or you simply just want to code and not wait for it.
Plus the better name is, the less need to write any kind of documentation for it, something us programmers really fear 😀
@jakub_neruda Oh yeah I totally agree! I'm not arguing against verbosity, just saying that english-like grammar symmetries have become less important to me than being able to write simpler more straightforward procedures.
Helpful verbosity is one reason I like namespaced functions:
`inst.Add(.1, .2, .3)`
At a quick glance, what is inst? But add is a perfectly reasonable method name... But!
`RGB.Add(inst, .1, .2, .3)`
That tells the whole story at once, and is easy to search for!
@ipsquiggle A half decent IDE is able to find you all instances of both approaches.
To be honest, both of your examples feel lacking to me.
a) I would wrap those three parameters into a "color" struct.
inst.Add(color) becomes much more expressive that way.
b) Using "inst" as a name instantly obfuscates the intent. If you call it "color" instead, you no longer need that namespace.
c) In this particular case, I would prefer the following syntax:
color += other_color
But I am unsure how many languages outside C++ allow operator overloading. Good for algebraic objects.