Something simpler?

Thu Mar 18 22:20:57 PDT 2010

1. Look at wild cards and Generics and say they are easy to read/understand. They do add complexity

2. Look at this

[:int] two = (:2);

assert two[] == 2;

a. is it easy to understand?
b. Does it look like Java ?

Put it to a poll if you like. I can't make head nor tail of it.

3. I did not say I was very concerned if  () was used, do not invent what I said. I said I was concerned with introducing ambiguity.
Of course I know where else () is used, that is not the point.
If you are expressing blocks of behavior use { } as it is most familiar, if you are expressing params use (), if you want to express something else, use something else

Basically I am coming from a perspective of someone who uses this language everyday for year on end, and understands the need for Closures.
Given that I am still using this language and not another one probably says a lot of what a success Java is and paramount to this succes is its simplicity.
What I don't want now is some Closure syntax the divereges from the current shape of the language and makes it a lot harder to understand and maintain for me and teams of developers with varying experience.

I don't want Java++

>From this debate I am not sure if you are looking at this as too much of an academic exercise in to what possible notation could cover every edge case, rather than being more pragmatic in the way Closures will feel and be used in the main.

Based on this debate clearly Gosling was right (or lucky) not to add them from the start.

________________________________
From: reinierz at gmail.com [mailto:reinierz at gmail.com] On Behalf Of Reinier Zwitserloot
Sent: Friday, March 19, 2010 1:44 PM
To: Knox, Liam (IDEAS)
Cc: Joshua Bloch; lambda-dev
Subject: Re: Something simpler?

I don't follow the argumentation used here. As far as I understand it, the only stated reason for why symbols that already have meaning shouldn't be used for something entirely different is because it might be confusing to those programmers who know of the existing feature but not of the new feature.

Just about every java programmer knows about javadoc. Therefore, either will be equally confusing.

Also, you say that you'd be very concerned if () was used for something other than parameter definitions, but it is already! It's not just already used for casts and expression precedence grouping, it is also used as delimiter in multi-argument statements (while, do/until, for, synchronized, if, and catch), and in the Reinhold Strawman, it is used BOTH as delimiter in a function type description, and as a block delimiter with implicit "return " at the beginning and ";" at the end. It's used everywhere. Unless the argument is "parens are already such a grab-bag, anyone seeing them will not be tempted to assume they mean any one particular thing". That seems like a rather silly argument as it leads to packing still more semantic meaning on top of an already semantically overcrowded symbol, making the problem worse.

I also strongly disagree that generics added readability complexity. On the contrary; they massively reduced it. In the old days, you saw "List" and you didn't know that much. In the 1.5+ days, you see "List<Set<String>>" and you know a lot more than you used to. Now you can read it right there on the spot. In the past you had to read entire paragraphs, sometimes multiple pages worth of source before you could figure out what that "List" even meant. Either way, though, the semantic meaning contained inside a function type + closure definition pair is equal between the Reinhold Strawman and the Levart Brace syntax, so generics doesn't seem relevant.

--Reinier Zwitserloot

On Fri, Mar 19, 2010 at 3:16 AM, Knox, Liam <Liam.Knox at morganstanley.com<mailto:Liam.Knox at morganstanley.com>> wrote:
# - 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> [mailto: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<mailto:jjb at google.com>> wrote:

> Reinier,
>
> On Wed, Mar 17, 2010 at 9:13 PM, Reinier Zwitserloot <
> reinier at zwitserloot.com<mailto: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.

--------------------------------------------------------------------------
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.