Still no typedef

[Andreas Leitgeb]

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.

As I said somewhere else already, I don't follow the logic of that
argument, since giving names to classes or methods is just the same
matter: you do not necessarily see the implementation at each use.

I do think, though, that "type inference" as mentioned elsewhere in the
thread might just as well solve the problem at hand. (Not that a typedef
didn't still have it's use.)

 

[Lew]

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

But the point is that "typedef" isn't considered by all to improve readability
for Java code. You begged the question and set up a straw-man argument.

Why have you suddenly started talking about "performance" when everyone else
was talking about source-code readability? (OK, writability - those talking
readability seem to not like "typedef".)

 

[Chris Dollin]

But the point is that "typedef" isn't considered by all to improve readability
for Java code. You begged the question and set up a straw-man argument.

Why have you suddenly started talking about "performance" when everyone else
was talking about source-code readability? (OK, writability - those talking
readability seem to not like "typedef".)

Count me as a counter-example to that claim. Being able to name things is
Good. You can name for meaning, not structure.

 

[Arnauld.Loyer]

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.

humpf...

Map<Foo<Comparator<Integer>>, Foo<Comparator<Integer>> is at least
less readable than
Map<FooInt, FooInt>, and it 's not about the easy typing my IDE
provides.

And again, it's still a "simple" generic definition.

Creating a specific class is not a general solution and so, for me, a
valid one.
And furthermore, it strongly tides to a specific implementation
(ArrayList in the StringList sample) or need to create a full
delegation pattern to handle the interface. List has about 20 methods
that must be implemented( oki oki my ide is smart and can generate it
but) why should i have to create a two hundred lines class :s to deals
with that

I would prefer an alias (some one talking about preprocessing
huhhh ) even it is scope dependant to prevent unknown or unwilling
issue. What the point if outside your alias scope you get the fully
qualified

 

[Arnauld.Loyer]

Count me as a counter-example to that claim. Being able to name things is
Good. You can name for meaning, not structure.

I strongly agree with Chris Dollin

 

[Patricia Shanahan]

Count me as a counter-example to that claim. Being able to name things is
Good. You can name for meaning, not structure.

Same here, especially with an IDE that lets me see how the name is
declared whenever I need to know that.

Patricia

 

[lord.zoltar]

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.

Man I totally hear ya!
I know I typed
ArrayList<GenericPair<String, ArrayList<String[]>>>
waaaay too many times yesterday.

typedef ArrayList<GenericPair<String, ArrayList<String[]>>>
NamedTable;

would have been nice.
I supposed I could write a wrapper class:

class NamedTable
{
private ArrayList<GenericPair<String, ArrayList<String[]>>> table;

....

}

but then I get stuck writing wrappers to all the accessor methods...

It's just syntactic sugar for type synonyms, but maybe this would be a
good use of typedefs. I never used generics like that in C++ so it
never mattered then.

 

[Matt Humphrey]

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

Abstraction is needed when the type expressions themselves become complex:

Map <NameId,Map<NameId,List<PrimaryActionDefinition>>> allPads
= new TreeMap <NameId,Map<NameId, List <PrimaryActionDefinition>>> ();

vs.

PrimaryActionTable = Map <NameId,Map<NameId,List<PrimaryActionDefinition>>;
PrimaryActionTable pat = new TreeMap <PrimaryActionTable> ();

I don't want to define a new class because doing so will bind the generic
expression to the base class. Using an interface is possible, but anonymous
instantiation always produces an inner class and naming the class results in
conflict between the unspecified generic type and the interface generic
type.

This works:
interface PrimaryActionTable extends
Map<NameId,Map<NameId,List<ElementalModelActionDefinition>>> {}

But this does not:
class PrimaryActionTableImpl extends TreeMap implements PrimaryActionTable
{ }

Cheers,
Matt Humphrey http://www.iviz.com/

 

[Andreas Leitgeb]

Count me as a counter-example to that claim. Being able to name things is
Good. You can name for meaning, not structure.

Me, four (after two more followup'ers)

 

[Piotr Kobzda]

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

class FooInt Foo<Comparator<Integer>>;

How about a bit different syntax for /type aliasing/ (good term?):

class FooInt = Foo<Comparator<Integer>>;

?

Of course, "tell the truth" rule is still needed, e.g.:

interface IntComparator = Comparator<Integer>;

The existing class declaration syntax does not allow the identifier
to be immediately followed by another identifier.

Yes, your proposal is enough, but with equals sign it seems to be
clearer that there is no new type defined (at least to me). It's just a
compile time defined type alias for already existing type.

Declaration scope
could be controlled by the same rules as for existing class declarations.

These rules may probably be reused. However, a maximum scope available
for alias should be likely a single compilation-unit. I'm afraid that
wider scope is to complex to become worthy of implementing in the
language. Without that needed, the compiler shall simply resolve each
alias to the real type.

In any case, I'm another one who'd like to have the type aliasing
feature available in Java.


piotr

 

[Steve Wampler]

How about a bit different syntax for /type aliasing/ (good term?):

class FooInt = Foo<Comparator<Integer>>;

?

Of course, "tell the truth" rule is still needed, e.g.:

interface IntComparator = Comparator<Integer>;
class FooInt = Foo<IntComparator>;

I also like this, if it's added at all...

I have some concern about adding a new language construct
simply because, well, it's adding a new language construct.
It's much easier to add new features than it is to remove
old ones, with the consequence that language complexity
goes up.

In this particular case, many of the benefits (but not all,
as others have pointed out!) of C's typedef can be provided
already by subclassing. So is it worth adding the above for
the net gain? Personally, I wouldn't do it but I'm certainly
not going to lose any sleep if it is done - and would
most likely use it, hypocrite that I am.

Incidently, I would argue that it would be better to do
the above than to implement the equivalent using a
preprocessor. The problem with a preprocessor approach
is that the change is cosmetic and not carried into
the runtime (hmmm, kinda like the current implementation
of generics...) *or* the compilation. Error messages
become more confusing, for example.

Using a preprocessor to *experiment* with a possible new
language construct *is* fair game, however - to see if the
perceived gains are worth it...

 

[Wojtek]

Roedy Green wrote :

On Wed, 5 Dec 2007 08:27:18 -0800 (PST), "Robert M. Gary"



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

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

This.

 

[Daniel Pitts]

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

Right, but FooInt is an interface to the class Foo<Comparator<Integer>>.

All that it *really* means is FooInt is an alias for
Foo<Comparator<Integer>>. Perhaps calling it a Type Alias is better
than a TypeDef.

Now that I think more about it, type aliases are another form of
abstraction/indirection that might be useful, especially if they are
implemented as more than typedefs in c++...

Imaging this:

class MyClass {
/* The following says,
ListType is the specific type we need,
and is assignable to List<FooBar>.
The fact that it is ArrayList is "hidden" from clients.
I'm assuming types would be static members automatically,
but if there were a way to have instance-specific types,
that would be even more "interesting".
*/
public type ListType implements List<FooBar> = ArrayList<FooBar>();
private ListType list;
public void setBackingList(ListType list) {
this.list = list;
}

public ListType getList() {
return list;
}
}

class OtherClass {
public void things() {
MyClass mc = new MyClass();
mc.setBackingList(new MyClass.ListType());
MyClass.ListType lt = mc.getList();
// lt's compile time type is List<FooBar> & MyClass.ListType.
MyClass.ListType doesn't expose ArrayList methods.}
}


This allows for a kind of interface that you can instantiate. Don't
mind me, random babbling and stream-of-consciousness dump.

 

[Daniel Pitts]

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

No law, but no existing process either. Well, unless you count AspectJ
or other AOP compilers. Or APT. Actually, maybe APT is what you want
Just, whatever you do, make sure that all the major IDE's can handle it,
through plugins and whatnot.

 

[Lew]

No law, but no existing process either. Well, unless you count AspectJ
or other AOP compilers. Or APT. Actually, maybe APT is what you want
Just, whatever you do, make sure that all the major IDE's can handle it,
through plugins and whatnot.

Isn't AspectJ actually its own compiler, not a preprocessor?

It's also a separate language from Java.

 

[Daniel Pitts]

Isn't AspectJ actually its own compiler, not a preprocessor?

It's also a separate language from Java.

My understanding is that its a language on-top of Java.

 

[Lew]

My understanding is that its a language on-top of Java.

Mine, too. It's that "on-top of" that I called "separate". (Java doesn't
have "join points", for example.)

I am only familiar with what I've read on their site. Doesn't it use its own
compiler?

 

[Arne Vajhøj]

Mine, too. It's that "on-top of" that I called "separate". (Java
doesn't have "join points", for example.)

I am only familiar with what I've read on their site. Doesn't it use
its own compiler?

It does.

But considering that Java source code and Java byte code is very 1:1
then the difference is not big.

Arne

 

[Arne Vajhøj]

Well, I don't really have time to teach you C++ templates in this
thread but I think if you did some research you would have a better
understanding of what they do. Besides, I already tought one class on
this at the University you could have attended that or you can do your
own research.

There are not much point in following a a class in programming
with a teacher which is so incompetent in programming that he
is not aware of the big differences between C++ templates
and Java generics.

Arne

 

[Lew]

There are not much point in following a a class in programming
with a teacher which is so incompetent in programming that he
is not aware of the big differences between C++ templates
and Java generics.

Based on certain internal evidence in the statement, whether he actually ever
"tought [sic]" at "the" or any other "University" lacks a degree of credibility.