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...
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.
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...).
Cheers,
mg
