Something simpler?

[Knox, Liam]

# - used already in java doc
[] - used already in java code

Being ambiguous in the Java Syntax seems much more concerning to me in these proposals
Being only a 'java programmer', I would not be happy with a syntax that introduces ambiguity in reading the code within a source file
{} as blocks and () for parameter definitions are very bread and butter in the understanding of all Java programmers

readability vs. functionality needs to be weighed up, as with Generics, for all their good, they did add a fair amount of readability complexity 

Two cents worth 

[:int] two = (:2);

assert two[] == 2;

Does not look like something simpler, and personally doesn't feel like Java

-----Original Message-----
From: lambda-dev-bounces at openjdk.java.net [mailto:lambda-dev-bounces at openjdk.java.net] On Behalf Of Reinier Zwitserloot
Sent: Friday, March 19, 2010 10:49 AM
To: Joshua Bloch
Cc: lambda-dev
Subject: Re: Something simpler?

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
>


--------------------------------------------------------------------------
NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law.