Something simpler?

[Reinier Zwitserloot]

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