Still no typedef

[Patricia Shanahan]

huh? why two FooInt's?

No need to get rid of that. If it's small enough, we really don't need to
overdo it.

"typedef" is not currently a Java keyword. Here's an alternative syntax
suggestion:

class FooInt Foo<Comparator<Integer>>;

The existing class declaration syntax does not allow the identifier
to be immediately followed by another identifier. Declaration scope
could be controlled by the same rules as for existing class declarations.

Patricia

 

[Daniel Pitts]

"typedef" is not currently a Java keyword. Here's an alternative syntax
suggestion:

class FooInt Foo<Comparator<Integer>>;

The existing class declaration syntax does not allow the identifier
to be immediately followed by another identifier. Declaration scope
could be controlled by the same rules as for existing class declarations.

Patricia

I think I would prefer interface over class for this.

 

[Patricia Shanahan]

I think I would prefer interface over class for this.

Perhaps it ought to tell the truth - use "interface" if
Foo<Comparator<Integer>> is an interface, "class" if it is a class.

Patricia

 

[Andreas Leitgeb]

I think I would prefer interface over class for this.

No, not really, afterall one should also be able to do
FooInt x=new FooInt(42);
lateron. IMHO, at least.

 

[Patricia Shanahan]

No, not really, afterall one should also be able to do
FooInt x=new FooInt(42);
lateron. IMHO, at least.

My alternative "tell the truth" proposal would allow this if FooInt is a
class. On the other hand, if it is an interface one should be able to say:

class SomeClass implements FooInt{
....
}

Patricia

 

[Steve Wampler]

class FooInt Foo<Comparator<Integer>>;

This isn't my area so feel free to tell me what I'm doing wrong, but
how would this be different than:

class FooInt extends Foo<Comparator<Integer>> {}

Wouldn't this be legal already?

Similarly for:

interface BazDouble extends Baz<Comparator<Double>> {}

 

[Patricia Shanahan]

This isn't my area so feel free to tell me what I'm doing wrong, but
how would this be different than:

class FooInt extends Foo<Comparator<Integer>> {}

Wouldn't this be legal already?

Similarly for:

interface BazDouble extends Baz<Comparator<Double>> {}

FooInt would only have a default constructor, regardless of the
Foo<Comparator<Integer>> constructors.

Patricia

 

[Wojtek]

Daniel Pitts wrote :

I believe you just made "long" a reference to the type "int" and then to
the type "LONG".

I also don't think you can override types like that.

Although, the point about #define is a good one.

The truth is that someone started out with an int, but should have used a
specific value type that avoids primitive obsession.
<http://virtualinfinity.net/wordpress/program-design/2007/10/28/primitive-obsession/>

Ok, then:

#define int long
#define LONG long

)

I did not use typdef when I was programming in C. At the time it seemed
like an overly complex way of doing things.

And you are right, there is no LONG on the C lexicon.

 

[John W. Kennedy]

FooInt would only have a default constructor, regardless of the
Foo<Comparator<Integer>> constructors.

And Foo might be final in the first place.

 

[Steve Wampler]

And Foo might be final in the first place.

Ah - got it. Thanks to both of you!

 

[Patricia Shanahan]

Ah - got it. Thanks to both of you!

More subtly, in the typedef approach I would expect FooInt.class to be
the same object as Foo.class. For purposes of reflection and debug,
FooInt really is Foo<Comparator<Integer>>, not one of its subclasses.

Patricia

 

[Lew]

Nonsense. You just define the constructors in the inherited class.

Might be. Usually isn't.

Given that Java does not, at this time, sport a "typedef" keyword, the
class-derivation technique will work in quite many cases. In fact, it's a
very common idiom. There are an awful lot of heritable classes to which this
would apply.

class Dao<T extends Entity> {...}
class User extends Entity {...}
class UserDao extends Dao<User> { ... stuff specific to User manipulation }

Of course, here we're doing much more than a typedef, we're actually defining
overrides and other specific behaviors for a User-level Dao class. We get the
compactness for free, this time.

 

[Patricia Shanahan]

Nonsense. You just define the constructors in the inherited class.

If defined the way Steve suggested, in the quoted message, FooInt indeed
only has a default constructor.

Assuming non-final Foo, FooInt could be defined to have a constructor
matching each accessible Foo constructor. However, defining FooInt is
then potentially much more complicated than with the typedef-like idea.

Patricia

 

[Tim Smith]

Some will consider this heresy, but there isn't actually any law against
using a preprocessor with Java.

 

[Andreas Leitgeb]

I did not use typdef when I was programming in C. At the time it seemed
like an overly complex way of doing things.

In C, the typedef was necessary for not having to use
the keyword "struct" all that often.

In C++, this is no longer the case, but typedef is still used to define
abstract system type names like time_t, pid_t,... and also to give
a simple name to complicated type constructs.

the latter would also be good use in Java.

 

[Andreas Leitgeb]

For Simplicity, I'll show how to do
typedef java.util.List<java.lang.String> StringList;
This can be done as follows:
class StringList extends java.util.ArrayList<java.lang.String>{}

This, however will still fail, if I wanted to save into
such a StringList-Variable an ArrayList<String> returned
from foreign code.

 

[Roedy Green]

I use Generic's a lot and
often find that declaring an iterator for a Generic can take two lines
of code.

why? See http://mindprod.com/jgloss/unmain.html

It is a feature that presents a dangerously strong temptation to write
unmaintainable, inscrutable code.

 

[Chris Dollin]

I feel that the burden of proof is on the typedef proponents to show how it
would serve in a more complex example. Nevertheless, I provided such an
example and how it actually does not favor typedef, in another part of this
thread.

The umpteenth time I wrote

Map<Node, Integer>

in recent code I gave up and wrote a subclass of HashMap<Node, Integer> with
a short [but meaningful] name and used that instead, vaguely confident that
no-one else was going to want to pass in their own Map<Node, Integer>.

Vaguely.

Had I been able to write something akin to

type Indicies = Map<Node, Integer>;

and used Indicies as the type I would have given audible thanks.

Being able to give names to things is a fundamental programming abstraction.

 

[Lew]

This, however will still fail, if I wanted to save into
such a StringList-Variable an ArrayList<String> returned
from foreign code.

I guess I understand what people think typedef will do, but I just don't have
such a hard time using List <String>.

And who uses fully-qualified names when they're griping about doing too much
typing?

I really don't even have trouble with Entity< Node, Renderer > either. Or
even Entity <Node, Renderer, Comparator< ? super Node >>. Or Map <Node,
Integer>. To my eye the typedef would just hide the vital information
revealed in the generics.

I would not favor adding "typedef" to the language. Just one more thing that
hides what a type is, making you look elsewhere in the code to understand it,
just because someone is too lazy to (let the IDE) type the generic types.

 

[Kira Yamato]

Not to mention, typedef has limited uses and doesn't actually improve code IMO.

You have to be kidding me. Code readability may not improve code
performance, but it certainly improve maintainability.