groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From MG <>
Subject Re: Omitting parentheses on .size() ?
Date Tue, 04 Aug 2020 15:19:00 GMT
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) :-)

*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

View raw message