Open letter to sun about java generics syntax

[javadesigner]

Dear Sun:

My suggestion is to ditch the proposed generics
syntax:

foo<bar>
List<String>

syntax and instead use:

foo/bar
List/String

Note, the current "List<String>" syntax, makes java
server pages, servlets and all code that mixes html,
xml and java be totally incomprehensible (because of
all the additional noise introduced by "<" and ">").

Also, if you code long enough, you suffer from
some form of carpal tunnel/rsi injury. Typing
shift + "<" + shift + ">" in the current generics
syntax is bogus and un-necessary. The current syntax
is also a direct copy of C++ and just as foo::bar() makes
no sense in java [foo.bar() is better and so is foo/bar].

JDK betas CAN be changed. There is no reason to use
"..<..>" and many reasons _not_ to.

"List/String" is way easier to type, to read and
does not conflict with html nor xml syntax.

Note, just as "<" and ">" in the current syntax have
no conflict with mathematical and shift operators, neither
will "/" have a conflict with division (since template
declaration syntax cannot appear in a expression).

I hope someone has the courage to examine this
proposal honestly and do the right thing.

Best regards,

--j

 

[Adam P. Jenkins]

Dear Sun:

My suggestion is to ditch the proposed generics
syntax:

foo<bar>
List<String>

syntax and instead use:

foo/bar
List/String

Have you thought about how you'd handle multiple type parameters, as in

Map<String, Date>

in your syntax, or nested generic declarations, where the type parameter is
itself a generic type

List< List<Integer> >

? Whatever you come up with would be pretty confusing without having an
open/close pair of characters delimiting the type parameter list. So it's
really just a question of which open/close pair of characters to use. Maybe

Note, the current "List<String>" syntax, makes java
server pages, servlets and all code that mixes html,
xml and java be totally incomprehensible (because of
all the additional noise introduced by "<" and ">").

I don't think this is a very strong point, since it already looks messy when
you use the < or > relational operators in JSP scriptlets. In fact
scriptlets just look messy, period. I don't think the Java language syntax
should be designed specifically to look nice embedded in XML documents.

Adam

 

[javadesigner]

Have you thought about how you'd handle multiple type parameters, as in

Map<String, Date>

Map/[String,Date]

in your syntax, or nested generic declarations, where the type parameter is
itself a generic type

List< List<Integer> >

List/[List/Integer] perhaps ?

? Whatever you come up with would be pretty confusing without having an
open/close pair of characters delimiting the type parameter list. So it's
really just a question of which open/close pair of characters to use. Maybe
they could have used [] instead of <> or something.

Good point. I don't know. But don't you think it's possible
to begin with the "foo/bar" syntax as the starting point
as oppose to starting with foo<bar> which makes everything
that follows much worse ?

Best regards,

--j

 

[Murray]

Have you thought about how you'd handle multiple type parameters, as in

Map<String, Date>

Map/[String,Date]

in your syntax, or nested generic declarations, where the type parameter is
itself a generic type

List< List<Integer> >

List/[List/Integer] perhaps ?

? Whatever you come up with would be pretty confusing without having an
open/close pair of characters delimiting the type parameter list. So it's
really just a question of which open/close pair of characters to use. Maybe
they could have used [] instead of <> or something.

Good point. I don't know. But don't you think it's possible
to begin with the "foo/bar" syntax as the starting point
as oppose to starting with foo<bar> which makes everything
that follows much worse ?

Best regards,

--j

I think using [ .. ] is a bad idea since that's the notation for accessing
elements of an array. I agree with Adam, it needs to be some sort of
enclosing notation to allow for "nesting". Which really only leaves ( ..)

Note, the current "List<String>" syntax, makes java
server pages, servlets and all code that mixes html,
xml and java be totally incomprehensible (because of
all the additional noise introduced by "<" and ">").

If you have a decent IDE/Editor with syntax highlighting, that shouldn't be
much of an issue.

 

[javadesigner]

I think using [ .. ] is a bad idea since that's the notation for accessing

elements of an array. I agree with Adam, it needs to be some sort of
enclosing notation to allow for "nesting". Which really only leaves ( ..)
{ .. } [ .. ] and < .. > I think the latter is the reasonable option since
it's the only one not being used in another context.

I just had a brilliant idea. Leave the <..> syntax if you
want for complex nested thingies. But _also_ allow
the "foo/bar" syntax for simple non-nested things.

I would venture to guess that 60% of collections are
simple lists of 1 data type, so instead of saying:

List<String>

_also_ allow

List/String

as a shortcut. Problem solved. Easier to type, easier
to read. (this would be similar to when anonymous array
initializers were introduced as a alternate array syntax).

--j

 

[Tor Iver Wilhelmsen]

My suggestion is to ditch the proposed generics
syntax:

foo<bar>
List<String>

It's not "proposed" anymore when the JSR has been approved and JRE
1.5/5.0 has reached the beta stage.

JDK betas CAN be changed. There is no reason to use
"..<..>" and many reasons _not_ to.

They cannot be changed this fundamentally.

But why not submit a new JSR on the subject? I am sure the JCP would
gladly postpone the eagerly awaited 1.5/5.0 in order to implement an
incompletely defined syntax that deviates sharply from the syntax used
in C++ (which they seem to be inspired by).

Open letters on some newsgroup do not suggestions to the JCP make.

"List/String" is way easier to type, to read and
does not conflict with html nor xml syntax.

You have an "American keyboard" focus. On some keyboards, / is on
shift + 7 - harder to type than e.g. < which is on a non-shifted key.

And you need a grouping system because the generics type definition
can and will have spaces, commas etc. in it.

 

[Thomas Schodt]

I just had a brilliant idea.

Had a hard time trying to figure out if you were being ironic.
Then I saw you are the OP.

easier to read.

How so?
"List<String>" stands out much better than "List/String".


If your concern is Java code that generates / parses *ml, I would
suggest you'd be better off hiding all those "<" and ">" by using final
strings for your *ml tags.

 

[Andrew Thompson]

Open letters on some newsgroup do not suggestions to the JCP make.

Quote of the Day? (very ..'Yoda') ;-)

 

[Sam]

Dear Sun:

My suggestion is to ditch the proposed generics
syntax:

foo<bar>
List<String>

syntax and instead use:

foo/bar
List/String

Have you thought about how you'd handle multiple type parameters, as in

Map<String, Date>

in your syntax, or nested generic declarations, where the type parameter is
itself a generic type

List< List<Integer> >

? Whatever you come up with would be pretty confusing without having an
open/close pair of characters delimiting the type parameter list. So it's
really just a question of which open/close pair of characters to use. Maybe

Note, the current "List<String>" syntax, makes java
server pages, servlets and all code that mixes html,
xml and java be totally incomprehensible (because of
all the additional noise introduced by "<" and ">").

I don't think this is a very strong point, since it already looks messy when
you use the < or > relational operators in JSP scriptlets.

Why does that make it not a strong point? I'd say it reinforces the
point. If relational operators look messy, then the more you add the
messier it looks.

In fact
scriptlets just look messy, period. I don't think the Java language syntax
should be designed specifically to look nice embedded in XML documents.

Adam

True, but if at all possible, optimize the "look" of the code to be as
pleasing as it can be when mixed in with xml, which it's bound to be
since html and xml are everywhere.

There has to be a better alternative. Anyway, generics as they appear
in 1.5 are an extremely watered-down version of templates.
Essentially all you get for all the extra syntax is that you don't
have to cast objects coming out of a collection. Big deal. (Ok, I may
be exaggerating, but that's the message that I'm getting right now).

Regards,
Sam90

 

[Cid]

There has to be a better alternative. Anyway, generics as they appear
in 1.5 are an extremely watered-down version of templates.
Essentially all you get for all the extra syntax is that you don't
have to cast objects coming out of a collection. Big deal. (Ok, I may
be exaggerating, but that's the message that I'm getting right now).

Well, to be fair, compile-time type checking is the big deal. Not
having to cast contents is just a side-affect of that significant
feature.

It's more of a big-project feature - to help prevent goof-ups when
lots of disparate developers are working with the same data structures
but not all with the same level of awareness.

If it bugs you, just stick to interfaces and responsible casting. We
got by this long without it just fine.

I'm more concerned about the metadata stuff. That kind of syntax
garbling is what made c++ hideous (MFC anyone?). VB.net suffers from
it too. I see the application, I just cringe at the thought of having
all that luggage hanging off my lovely well formed code.

 

[Mark Thornton]

Dear Sun:

My suggestion is to ditch the proposed generics
syntax:

The right time to make such suggestions has long passed. If you are
genuinely interested in such matters you should pay attention to the
Java Community Process, and at least respond to the public draft if not
actually become a member.

Mark Thornton

 

[javadesigner]

The right time to make such suggestions has long passed. If you are
genuinely interested in such matters you should pay attention to the
Java Community Process, and at least respond to the public draft if not
actually become a member.

Mark Thornton

Nah. This ain't rocket science. Sun can always make any change they
want anytime they want. The guy who wrote unix 'make' didn't resolve
the space vs. tab because he already had, like, 4 users when the
problem was found. The decision not to fix the problem ("it's too
late", "we already have users") etc., is almost always wrong. Fix
it if it clearly needs fixing. Arbitrary timelines don't matter.

But does it need fixing ? Is my proposal sound ? That's the main
question.

As people have cogently pointed out, generics syntax needs both open
and close delimiters to capture nesting. So there may be no
replacement for constructions of the form
"<..<...>, ...>" etc.

But easy to type alternatives for the common case:

List/String

can easily be added to Java 1.4. Consider it syntactic sugar.

If you look at java code on the server (face it, that's where java
has primary and huge ussage), you'll see html/xml everywhere. Using
angle brackets "<" and ">" not only involves tired hands (shifting
on US keyboards) but java code with templates looks really really
noisy.

In fact, almost 2 years ago, it was I who originally proposed:

List of (List of String)
List of String

That's a really neat way of doing things in my opinion. Sun choose
not to use that syntax because the generics people are C++ lovers
and they incorrectly said that using "of" would break existing code.
That's clearly untrue, just as using "<" in generics syntax does NOT
break existing code.

Best regards,

--j

 

[Roedy Green]

So there may be no
replacement for constructions of the form
"<..<...>, ...>" etc.

I dislike <> on aesthetic grounds alone. What about [] or even ()?

Are types really all that different from ordinary parameters?

 

[Adam P. Jenkins]

So there may be no
replacement for constructions of the form
"<..<...>, ...>" etc.

I dislike <> on aesthetic grounds alone. What about [] or even ()?

Are types really all that different from ordinary parameters?

If you used (), then expressions like
new LinkedList<String>(someCollection)
would look pretty confusing:
new LinkedList(String)(someCollection).
Same thing with []. To create an array of generic types, instead of
new GenericType<String>[20]
you'd have
new GenericType[String][20]

So when it comes down to it, <> isn't a bad choice for readability. Of
course I learned C++ before Java so I may be biased. I think the "of"
keyword might have been nice if generics had been added earlier, but it
would break too much code at this point.

List of String aList;
Map of String, Integer aMap;

Adam

 

[Roedy Green]

If you used (), then expressions like
new LinkedList<String>(someCollection)
would look pretty confusing:
new LinkedList(String)(someCollection).

Then you get confused between casts and generics.

I wondered if it might be possible to implement generics not treating
the types as all that special. They are just ordinary parameters, that
happen to be of type Type.

The problem is they are parameters of the type declarations as well as
the objects.

I would have liked to say something short and simple like this to
declare without spelling all the type info twice.


Vector( Dog, 100 ) v;


instead of

Vector<Dog> v = new Vector<Dog>( 100 );

How about?

Vector[Dog] v = new Vector[Dog] ( 100 );

Now it gets really weird if you had an array of vectors

Vector[Dog][] v = new Vector[Dog][ 50 ];

At least they did not reuse {} yet again!

Sun hates new keywords. but you could have done:

Vector of Dog v = new Vector of Dog( 100 );

complex of clauses could be wrapped in ().

Maybe even:

Dog Vector v = new Dog Vector( 100 );

 

[Tor Iver Wilhelmsen]

Nah. This ain't rocket science. Sun can always make any change they
want anytime they want.

No, because they have submitted to the rules of the JCP. You are
confusing Sun with Microsoft; Microsoft are under no obligation to
follow such a process.

The decision not to fix the problem ("it's too late", "we already
have users") etc., is almost always wrong. Fix it if it clearly
needs fixing. Arbitrary timelines don't matter.

But your syntax is less useful than the current syntax, so it does not
constitute a "fix".

But does it need fixing ? Is my proposal sound ? That's the main
question.

It's not, because it's alien from how its C-family "siblings" do it.

In fact, almost 2 years ago, it was I who originally proposed:

List of (List of String)
List of String

Why mix Pascal syntax into a C-family language?

and they incorrectly said that using "of" would break existing code.

It would! That's the point of reserving certain words as keywords, you
make sure they're not used as variable names. This is why programs
that used "delegate" as a variable name failed to compile when
Microsoft introduced that keyword in their dialect of Java.

That's clearly untrue,

Are you totally ignorant as to how a parser functions in a language
that uses keywords?

 

[P.Hill]

I wondered if it might be possible to implement generics not treating
the types as all that special. They are just ordinary parameters, that
happen to be of type Type.

The problem is they are parameters of the type declarations as well as
the objects.

I'm not sure what you are getting at when you say they are "ordinary
parameters". I was under the impression it was all in the class compilation
phase which resulted in code with appropriate casting and/or type checking.
Certainly no extra or hidden runtime parameters.

-Paul

 

[Roedy Green]

I'm not sure what you are getting at when you say they are "ordinary
parameters". I was under the impression it was all in the class compilation
phase which resulted in code with appropriate casting and/or type checking.
Certainly no extra or hidden runtime parameters.

Obviously, under the hood the types are special. They don't even show
up in the underlying code. Generics are primarily a compile time
phenomenon, with a few cast checks through in.

What I meant was, from the programmer's point of view, they are just
another parameter. Maybe we don't need to treat them like holy relics
surrounding them in golden horns < >.

 

[Hamilcar Barca]

Dear Sun:

My suggestion is to ditch the proposed generics
syntax:

foo<bar>
List<String>

Sun began soliciting proposals for adding generics around eight years ago
the basis for the Java 1.5 changes (Pizza) is seven years old. Perhaps
you were unaware of the significant amount of work done by researchers
around the world; Sun's additions are certainly not perfect but they're
about as good as can be expected.

foo/bar
List/String

You fail to discuss bounds and wildcards, and these are not trivial issues.

Also, if you code long enough, you suffer from
some form of carpal tunnel/rsi injury.

Java's already a verbose language.

If you want your ideas to be taken seriously by Sun, you must examine all
the issues, present them in a timely manner, and refrain from immaterial
claims.

I hope someone has the courage to examine this
proposal honestly and do the right thing.

Your proposal is trivial and without value.

 

[Hamilcar Barca]

So there may be no
replacement for constructions of the form
"<..<...>, ...>" etc.

I dislike <> on aesthetic grounds alone. What about [] or even ()?

They all have problems. Brackets look like array index delimiters and
parentheses look like method invocations. Less-than/greater-than were
likely chosen because of their use in C++.

Are types really all that different from ordinary parameters?

Yes. Type parameters are "erased" at compile time. There were proposals
to include types (virtual types) at run time -- as happens now with array
types. Apparently Sun didn't like that idea as much as parametric
polymorphism. Both ideas have their strengths and weaknesses.