Community
Participate
Working Groups
(from https://github.com/golo-lang/golo-lang/issues/278) I don't think I need to describe operator overloading. My question is why not implementing them in Golo. augment java.util.List { function plus = |this, element| { if element oftype Collection.class { this: addAll(element) } else { this: add(element) } return this } } let data = list[1,2,3] println( data + 4) #Prints [1,2,3,4] Regarding the implementation, OperatorSupport is already mapping the operator symbol (e.g. "+") to a function plus(left, ritgh). Currently generic calls plus(Object, Object) are simply rejected. The aim would allow these calls and try to find their definition in the receiver class augmentation. Would be interesting to merge OperatorSupport with MethodInvocationSupport. Boxed primitives types will be augmented in standard-augmentations with their native operators (plus, minus,etc) and user defined operators will follow the same resolution path as a "normal" augmentations. Thoughts? ---- Yannick Loiseau: I like the idea (very pythonish) and I was also thinking about it for some times… However, since doing this “reserve” the method name for a special purpose, I'd use a less common name for the “operator method”, e.g. (python-like) __plus__ to avoid name clashes. On merging OperatorSupport with MethodInvocationSupport, why not :smile: BTW, this could quite easily be made with macros :wink: On a other hand, operator overloading can be quite complex. As an example, your toy implementation of + on lists has several problems (I know it's just an example): * should be sides-effect free (i.e. return a new list without changing the original one) * list[ list[1,2], list[3, 4] ] + list[5, 6] will return list[ list[1,2], list[3, 4], 5, 6] while I wanted list[ list[1,2], list[3, 4], list[5, 6]], and I thus must use add (python does the same thing btw). I don't say we should not go this path, just that is can be less trivial (from a semantic pov) than is seems ---- Julien Ponge: I am always very cautious of operator overloading... ---- Daniel Petisme: @yloiseau Indeed the implemntation is not perfect at all :smile: @jponge what are your concerns? ---- Julien Ponge: I’m always worried with operators overloading. ---- Daniel Petisme: A synthesis of talks with @yloiseau and @jponge The aim of operator overloading is just to map a symbol (+) to a function (plus), and let the possibility to the dev to overload this functions. Operators are nothing more than syntaxic sugar. Use cases Algbric types Pros: It's the more natural use case augment Complex { function plus = |this, other| -> Complex(this: real() + other: real(), this: imaginary() + other: imaginary()) } Cons: Commutativity is tricky and could make Golo looks like a living javascript hell "1" + 2 == "12" 1 + "2" == 3 Collections Pros: how cool is that let data = list["a"] * 3 + "b" #["a", "a", "a", "b"] Cons: Commutativity 1 + [1,2] VS. [1,2] + 1 + the set of usefull is quite limited (+, -, maybe *). Other What sould produce the following simppet? DynamicObject():name("Duke") + DynamicObject:name("Scarlette Johanson") How it would behave in a DSL Implementation Operator candidates What could be overloaded or not +, -, *, /, % is, isnt and, or, not <, <=, ==, !=, >, >= :, ?:, () [] Macros or not macros Macros would permit the user to define its own operators which will be translate into standard Golo code during the pre-compile stage. "1" &+ 2 the operator is flagged by & (more or less readable?). This approach permits to keep the Golo language "clean" and also offer the feature. The dev will choose if it prefers to use standard functoin call or custom operators. Personal thought For me, even if macros flag the operators, it's the more permissive and safe way to propose operator overloading in Golo.
