Something simpler?

[Reinier Zwitserloot]

But "#", from its javadoc roots, suggests type member, which is just as
completely off base as [] suggesting array access. If we want lean syntax I
think overloading the semantic meaning of a few symbols is inevitable. It
would be good if we picked symbols that read naturally yet don't have too
many commonly used meanings in today's java, and with arrays moving ever
further towards the background, [] is a fair suggestion.

FWIW, I would prefer it if closure invoke remained .(), because unlike any
of the other usage of [] in the Levart Bracket proposal, that *can* be
mistaken for array deref.

Then again, there's a coin proposal that was taken quite seriously which
aims to introduce operator overloading to java and make
expressionA[expressionB] mean: Check if expressionA implements
ListAddressable, and if so, compile this expression as if it read
expressionA.get(expressionB). The theory here is presumably that doing an
indexed retrieval on a list-like object is sufficiently similar to an array
access that using brackets is acceptable. But that's not the end of that
particular line of thought - you end up with the conclusion that calling a
method that takes 1 integer and returns something is theoretically
retrofittable as 'list-like' and as there are plenty of concepts that aren't
really implemented as physical list-like constructions that nevertheless
could and probably will end up as such ListAddressable instances (such as
e.g range(10,1000)), we must conclude that in fact any method call is
sufficiently similar to arrays, so that if this ListAccessible proposal is
acceptable, then brackets are acceptable for methods.

And if method calls are sufficiently similar to array access, then so is
closure invocation.

There's also the idea of allowing [] or {} to be used for collection
literals. {} in java right now means "block" or "body" and nothing else. It
has nothing to do with maps or even literals. Your same argument would apply
there. Why is this the first time you're complaining about '[', ']', '{' and
'}' being used for things that don't mean what they do in Java6? If anything
this proposal should receive _more_ leniency than the others, because its
already so complicated in other areas, too.

Just playing advocate of the devil. Personal vote: Go with .() instead, and
the reasoned argument behind it is this: [] is for arrays and not for
anything else. Don't introduce [] access for Lists either*.


*) Or, tilt the other way and go whole hog with operator overloading.
Consistency is worth something.

--Reinier Zwitserloot



On Thu, Mar 18, 2010 at 11:28 PM, Joshua Bloch <jjb at google.com> wrote:

> Reinier,
>
> On Wed, Mar 17, 2010 at 9:13 PM, Reinier Zwitserloot <
> reinier at zwitserloot.com> wrote:
>
>> I just don't understand how this works. Some syntax doesn't feel right to
>> someone, and the magic words "This isn't java" are spoken. Is there some
>> sort of device to measure this property? I'd love to get my hands on a
>> javometer.
>
>
> I don't have a Javometer, but my assertion isn't arbitrary, and it isn't
> purely aesthetic (though it does have an aesthetic component). Looking at
> the proposed syntax, I can tell you why it doesn't look like Java:
>
> [:int] two = (:2);
> assert two[] == 2;
>
>
> Java declares return types *before*  variables and doesn't use the colon
> to indicate the return type. Other languages (such as Pascal and Scala) put
> the types after the variable name, separated by a colon. So this is a
> specific point where the proposed syntax deviates from established Java
> norms.
>
> Also, brackets strongly suggest arrays to existing Java programmers,
> especially when preceded by an identifier.  This is even more true if the
> brackets contain an integer-valued expression:
>
>    assert x[i] == 42;
>
> If x[i] could be a lambda invocation as well as an array reference in the
> above statement, we've done real harm to the language.
>
>           Josh
>