Nice to @Share?

Reinier Zwitserloot reinier at zwitserloot.com
Thu Feb 25 09:19:23 PST 2010


On Tue, Feb 23, 2010 at 2:23 PM, Rémi Forax <forax at univ-mlv.fr> wrote:

>
> Reiner,
> I think you can introduce any keyword before a local declaration without
> breaking compatibility.
> So the best is to choose a keyword that means what you really want.
>

That's not really true - lets say the keyword becomes 'modifiable', then
this would be legal:

modifiable modifiable modifiable;

and backwards compatible, but it won't be readable and will cause anyone
seeing it to do a double-take. It's not that big of a deal, the amount of
types out there called 'modifiable' (with lower casing) is probably 0, and
not that many variables will be called 'modifiable' either, but just proving
a point. It's also somewhat easier for the parser to generate sane error
messages if the amount of context-sensitive keywords are kept to a minimum
(if modifiable is used wrongly and it is a context sensitive keyword, then
the parser must erroneously conclude that it is not a keyword, and likely
attempt a spectacularly wrong interpretation of what you were trying to
write, resulting in a suboptimal parse error. By overriding the meaning of
keywords, you run similar risks, but these seem somewhat smaller to me -
even if the parser can't tell what kind of 'public' you are talking about,
enumerating the possible meanings is more straightforward).

These are all relatively insignificant arguments, but the more I think about
it, the more 'public' seems like a good name for it, and the fact that it's
an existing keyword is a coincidence. The best alternative keyword I've come
up with is 'modifiable', but that's somewhat hard to type (also a relatively
insignificant argument, but a decent tie breaker) and still doesn't really
cover the meaning that well. The meaning is better covered with "nonfinal"
(to highlight that you explicitly do not intend for it to be implicitly
final), but that feels a bit awkward.



>
> By the way, I am very happy with final (or implicit final).
> When I code and find that I need a non-final local variable,
> I first try to rewrite the code to avoid to use non-final
> before trying to use a mutable object.
>
> <T> void foreach(List<T> list, #void(T) fun) {
>   for(String element: list)
>     fun.invoke(element);
> }
> ...
> @shared int length = 0;
> foreach(alist, #(String element){
>    length += element.length;
> });
>
> can be rewritten as:
>
> <T> int reduce(List<T> list, #int(T, int) fun, int acc) {
>   for(String element: list)
>     acc+= fun.invoke(element);
>    }
>    return acc;
> }
> ...
> int length = reduce(alist, #(String element, int acc) {
>    return element.length + acc;
> });
>
> In my opinion, @Shared is not that important if you provide APIs
> to easily play with collections.
>
> [...]
>
> > --Reinier Zwitserloot
> >
>
> Rémi
>
>


More information about the lambda-dev mailing list