groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From OCsite <>
Subject Re: Omitting parentheses on .size() ?
Date Tue, 04 Aug 2020 14:22:49 GMT

> On 4 Aug 2020, at 16:13, MG <> 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,

View raw message