On Mon, Mar 23, 2009 at 5:13 PM, Levi Bard <[email protected]> wrote: >>> At the same time, by having operator overloading we can have our >>> own implementation for any arithmetic operation over any kind of >>> object which will make Vala a more flexible language and this will >>> open lot of possibilities in video game programming. > > This is, at best, syntax sugar. It doesn't add any flexibility to vala > (simply calling a method named "operator+" instead of a method called > "add"), and adds great potential for confusion. How this relates to > video game programming is beyond me.
A typical thing i used to see when modding Half-Life is the Vector class which allows you to do vector math as though you were dealing with simple types. vector.x *= 5; vector.y *= 5; vector.z *= 5; becomes vector *= 5; You can also add vectors together and so on. It's certainly *not* something that is ground breaking and that would bring massive improvements to the game development community. That said, in the + vs method call case, consider vector1.add(vector2) - does it add the vectors together and store in vector1, or does it return a new vector. For this kind of thing, + and += have clearer and more established intentions, i think. >>> Another nice feature would be to add an 'auto-cast' capability using >>> code attributes over the class definitions to simplify the code writing >>> when a cast is necessary to be done. for example: >> >> This is flexible in writing, but unreadable for the reader. To >> understand string str = obj, the reader has to find the definition of >> Object, search for all autocast annotations, then guess which is which. >>> [...] >> The more complex the situation gets, the more difficult for the reader >> to understand the code. Verbosity is not always bad, given that our >> brains are not compilers. > > Here, I agree with Yu Feng. > In addition, these features, while questionable by themselves, become > nightmarish in combination. > What happens when using overloaded operators to add a Foo and a Bar, > both of which are implicitly castable to each other? What about when > there is a complex graph of implicitly castable types? > Sure, it's possible to define rules for these sorts of complicated > situations, but that means that the reader has to navigate that > ruleset every time that code is used, and the developer has to > renavigate that ruleset every place it's used every time any > contiguous code changes. > > A good programming language makes it easy to create maintainable code > and to maintain and reuse existing codebases, not just to spew out > unreadable throwaways using a minimal number of characters. > I'm against operator overloading in general, but wouldnt be opposed to a limited enough subset that allowed e.g. the Vector stuff but stopped crazy uses (C++ style omg << i << hate << that). I'm not convinced thats possible, though... John _______________________________________________ Vala-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/vala-list
