On 04/08/2020 16:22, OCsite wrote:
Having too many operators is like having too many annotations: People don't
know about them, and therefore do not use them, or are confused if they do
encounter them
(see also e.g. Scala as an example of a language where people can define their
own operators, and to what problems that can lead...).
Do please correct me if I am wrong, but I do believe user-defined operators
would not lead to such a mess as language-defined ones by far; you would simply
use your own ones and would not get bitten in your tender parts by those
defined by others.
Herin exactly lies the problem: In the end people start to define their
own language, which at some point becomes impossible to read/parse by
other devs. Just google Scala and operator overloading. While I am not
for trying desperately to block developers from doing stupid things,
this is alas evidently one of those features that can very easily be
abused, so having a fixed, standardized set of operators in a language
is imho the better choice. I use operator overloading in my framework,
e.g. by adding the capability to add together Column objects to form a
Columns object, but I have never felt the need to define a completely
new operator like "**!".
Of course one could argue that one can define ones own language in
Groovy anyway, by using its DSL features, but in practice that takes
much more effort, and is a more concious decision than simply defining
your own custom operator here, and here, and here...
Of course your opinion may vary, but I that is my reason why I currently
would be -1 on arbitrary custom operators in Groovy - sometimes with too
much power comes too much responsibility (and too little advantage imho) :-)
Cheers,
mg
*with the special behavior that a column will not be added if it already
exists in the Columns obj, so one can write e.g. p.AGE.val(33) +
p.ID.val(newId()) + p.LAST_NAME.val('Muster') + p.allColumns and always
get all the p(erson)'s columns
