1.5 Question dealing with inheriting from a Collection class

[cbongior]

I would like to create a class that inherits from a TreeMap and somehow
(for autoboxing, iterating and other typing purposes related to 1.5)
tell the compiler that map backing this class what types it contains.
Here is the code -- I think you will see what I mean. Specifically to
avoid this UGLY syntax: List<SearchResult> results =
(List<SearchResult>)super.get(fieldName);

What is the syntax for telling 'super' what types it will contain?

Christian


private static class SearchResults extends TreeMap{
private List<Long> recNums = new ArrayList<Long>();

public void addResult(String fieldName,SearchResult res) {
List<SearchResult> results = (List<SearchResult>)
super.get(fieldName);
if(results == null)
results = new ArrayList<SearchResult>();
results.add(res);
super.put(fieldName,res);
recNums.add(res.getRecordNumber());
}

public void addResult(Field f,String criteria,Record r) {
addResult(f.getName(),new SearchResult(f,criteria,r));
}

public long[] getRecordNumbers() {
int i = 0;
long[] retVal = new long[recNums.size()];
for (Long rec : recNums)
retVal[i++] = rec;

return retVal;
}
}

 

[Timbo]

Inheriting from TreeMap<String, SearchResult> instead of just
TreeMap should do the trick.

 

[Thomas Weidenfeller]

I would like to create a class that inherits from a TreeMap and somehow
(for autoboxing, iterating and other typing purposes related to 1.5)
tell the compiler that map backing this class what types it contains.

You already got pointed to TreeMap<String, SearchResult>, however, there
are a couple of other issues with that code.

private List<Long> recNums = new ArrayList<Long>();

Since you later anyhow loop through that list, why not just iterate over
the TreeMap to get the record numbers?

public void addResult(String fieldName,SearchResult res) {
List<SearchResult> results = (List<SearchResult>)
super.get(fieldName);
if(results == null)
results = new ArrayList<SearchResult>();
results.add(res);
super.put(fieldName,res);

There is no need to add the entry again, if it already exists. The put()
should apparently also put 'results' and not 'res' to the tree,
otherwise you are creating the ArrayList for no apparent reason.

if(results == null) {
results = new ArrayList<SearchResult>();
put(fieldName, result);
}
result.add(res);

recNums.add(res.getRecordNumber());

As already mentioned, you should have a good reason to remember the
numbers individually.

/Thomas

 

[Dale King]

I would like to create a class that inherits from a TreeMap and somehow

I would say it rarely ever makes sense to extend a collection class.
Composition almost always makes more sense than inheritance.

A prime example of a bad use of inheritance of a collection class is
java.util.Properties. It extends Hashtable. It is hardcoded that it is a
Hashtable. We can't use a HashMap, a TreeMap, or LinkedHashMap.

 

[Scott Ellsworth]

I would say it rarely ever makes sense to extend a collection class.
Composition almost always makes more sense than inheritance.

A prime example of a bad use of inheritance of a collection class is
java.util.Properties. It extends Hashtable. It is hardcoded that it is a
Hashtable. We can't use a HashMap, a TreeMap, or LinkedHashMap.

Even more loathsome - one can take a Properties and add values other
than Strings to it by using the Map interface. Then, when you try to
write them to disk, you get a class cast exception.

Lousy design, up there with inheriting Stack from Vector, rather than
composing.

Scott

 

[Roedy Green]

Lousy design, up there with inheriting Stack from Vector, rather than
composing.

What would be the differences had stack not extended Vector?

I was very frustrated I could NOT just extend DataInputStream for a
little endian version. Every single method had to be wrapped even if
the wrapper did nothing.

 

[Patricia Shanahan]

What would be the differences had stack not extended Vector?

1. If it had not inherited Vector's methods one could assume LIFO
behavior, without having to check every use of it.

2. Sun would have had the option of basing it on ArrayList, or any other
List implementation, instead of being tied to basing it on Vector.

I was very frustrated I could NOT just extend DataInputStream for a
little endian version. Every single method had to be wrapped even if
the wrapper did nothing.

What was the problem with extending DataInputStream?

Patricia

 

[Roedy Green]

What was the problem with extending DataInputStream?

It is final.

I'm trying to think the term for it. I had a DataInputStream
reference inside my own LeDataInputStream.

I had to provide wrapper methods to simulate all the features of
DataInputStream though none were inherited from DataInputStream.

 

[Patricia Shanahan]

It is final.

I'm trying to think the term for it. I had a DataInputStream
reference inside my own LeDataInputStream.

I had to provide wrapper methods to simulate all the features of
DataInputStream though none were inherited from DataInputStream.

DataInputStream itself does not seem to be final. However, I've since
noticed that numerous methods, including the ones you would have wanted
to override, are themselves gratuitously final.

That means that one could extend it with e.g. readDoubleLE that returns
the next element interpreted as a little-endian double, but it is
unfortunately not possible to make readDouble do it.

Patricia