Guys, > On 4 Aug 2020, at 16:13, MG <mg...@arscreat.com> wrote: > On 04/08/2020 15:16, Basurita wrote: >> On 8/1/20 14:41, MG wrote: >>> Hmmm, I am for consistency, but at least I use very few maps as compared to >>> lists, and rarely ever output the size of a map, but constantly for >>> lists, so having getSize() on List would still be beneficial. >> You're free to add whatever you want to your metaClass :-) > > In dynamic Groovy, yes, but I am an IntelliJ / @CompileStatic Groovy user so > afaiaao there is no way to make this work in my case...
(Offtopic: lucky me I never use CompileStatic. Does it really prevent adding new methods/properties through the metaclass?!? Ick!) >>> This has of course been discussed many times before - maybe a "size" >>> operator: >>> >>> #list // list.size() >>> #map // map.size() >>> #string // string.length >> Now, this is not a completely bad idea. >> I spent a few years programming in Lua, and that's what the # operator does >> for strings and tables (arrays) > > I was not aware of that, "#" just seemed like a workable choice since is > already used as an abbreviation for "how many / number of" in English. Also pretty frequently used as the size/count operator in shells. >> i think the # symbol is not being used in Groovy anywhere but I may be >> mistaken. >> They would need to change the language's grammar, though. > > The hard part would be a) agreeing whether the operator makes sense in > principle (I just put the idea out there, since I feel Collection#getSize() > might never happen), and then b) agreeing on a symbol for it. > Implementing the change would be straightforward in comparison ;-) > >> I'm all for using symbols for syntactic sugar. >> And why limit ourselves to ASCII-7 when we have the whole Unicode set to >> choose from!! :-) > > 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. And if you define them in a stupid way, you'd get precisely what you deserve :) The possibility to define own operators (preferably through the metaclass without a need to go ASTTs) would be, in my personal opinion, pretty nice — but I am afraid it would be a pure hell for the parser, would it not? All the best, OC
