|
|
| deelBlue 2008-03-13, 8:03 pm |
| Hi ,
I am trying to program a stack with an array, the interesting part of the
implementation looks like :
public class Stack<T> {
T[ ] field;
Stack(){
field=new T[10];
}
}
but I am getting a compiler error by creating the field (new T[10] ).
can some one help me please.
| |
| Eric Sosman 2008-03-13, 8:03 pm |
| deelBlue wrote:
> Hi ,
>
> I am trying to program a stack with an array, the interesting part of
> the implementation looks like :
>
> public class Stack<T> {
>
> T[ ] field;
>
> Stack(){
> field=new T[10];
> }
>
> }
>
> but I am getting a compiler error by creating the field (new T[10] ).
It's a FAQ:
http://www.angelikalanger.com/Gener...rizedTypes.html
.... and look for "Can I create an array whose component type
is a concrete parameterized type?"
--
Eric.Sosman@sun.com
| |
| Mark Space 2008-03-13, 8:03 pm |
| Eric Sosman wrote:
> It's a FAQ:
>
> http://www.angelikalanger.com/Gener...rizedTypes.html
>
>
> ... and look for "Can I create an array whose component type
> is a concrete parameterized type?"
>
So many problems would be solved if Sun just got rid of erasure. I hope
they do in Java 7.
| |
| Roedy Green 2008-03-14, 8:20 am |
| On Thu, 13 Mar 2008 21:13:18 +0100, "deelBlue" <deel007@hotmail.com>
wrote, quoted or indirectly quoted someone who said :
>
>but I am getting a compiler error by creating the field (new T[10] ).
you have to cheat. For why see
http://mindprod.com/jgloss/generics.html
To figure out how to kludge, see the links in that essay or study how
Sun cheats in classes like ArrayList.
--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
| |
| Jan Thomä 2008-03-20, 8:19 am |
| Mark Space wrote:
> So many problems would be solved if Sun just got rid of erasure. I hope
> they do in Java 7.
They prolly won't as it would break backwards compatibility which was the
whole idea about erasure IIRC...
--
________________________________________
_________________________________
insOMnia - We never sleep...
http://www.insOMnia-hq.de
| |
| Mark Space 2008-03-20, 7:23 pm |
| Jan Thomä wrote:
> Mark Space wrote:
>
> They prolly won't as it would break backwards compatibility which was the
> whole idea about erasure IIRC...
>
>
>
I understand. However, I think there's a time to maintain
compatibility, and a time to break it. There has to be some way to
introduce reifiability (sp?) with the minimum of disruption.
I think some new types in the collection interface (RefiableHashMap,
RefiableTreeSet, etc.) and a modification to the generic syntax for
reifiable types would allow backwards compatibility with the old types
while giving folks the option to move to reifiable types.
| |
| Jan Thomä 2008-03-28, 8:17 am |
| Mark Space wrote:
> I think some new types in the collection interface (RefiableHashMap,
> RefiableTreeSet, etc.) and a modification to the generic syntax for
> reifiable types would allow backwards compatibility with the old types
> while giving folks the option to move to reifiable types.
Well they did that in Dot.Net which introduced a lot of headaches because
you could no longer use libraries that used untyped collections together
with typed collections. So if you wanted to use a library that was still
using the old collections together with a project of yours that used the
new collections you were basically stuck. That's why i think the erasure
concept is a bit more clever in that regard. Actually i didn't have any big
issues with erasure apart from the fact that you cannot do a new T() thingy
but i find Sun's solution a lot more elegant than Microsoft's which
basically breaks backwards compatibility. But am not trying to incinerate
holy war here. In case you really need to do something like new T() you can
still do something like that
T create(Class<T> clazz) {
T result = clazz.newInstance();
}
Granted, not as nice as a new T() but i'd trade this for backwards
compatibility every time.
My $0.02 ;)
--
________________________________________
_________________________________
insOMnia - We never sleep...
http://www.insOMnia-hq.de
| |
|
| Jan Thomä wrote:
> T create(Class<T> clazz) {
> T result = clazz.newInstance();
> }
>
> Granted, not as nice as a new T() but i'd trade this for backwards
> compatibility every time.
If you already have a Class<T> instance, you don't need a cover function for
your one-line call to newInstance(). Now, if you were to encapsulate the
error-handling in that one-liner, it very likely is worth the cover function.
--
Lew
| |
| Roedy Green 2008-03-28, 8:17 am |
| On Fri, 28 Mar 2008 11:25:34 +0100, Jan Thomä <kork@insomnia-hq.de>
wrote, quoted or indirectly quoted someone who said :
>Well they did that in Dot.Net which introduced a lot of headaches because
>you could no longer use libraries that used untyped collections together
>with typed collections. So if you wanted to use a library that was still
>using the old collections together with a project of yours that used the
>new collections you were basically stuck. That's why i think the erasure
>concept is a bit more clever in that regard. Actually i didn't have any big
>issues with erasure apart from the fact that you cannot do a new T() thingy
>but i find Sun's solution a lot more elegant than Microsoft's which
>basically breaks backwards compatibility. But am not trying to incinerate
>holy war here. In case you really need to do something like new T() you can
>still do something like that
I had a talk with Bill Joy a few years back when he came to the
Colorado Software conference. I felt quite elated afterwards mainly
because I learned many of the things Sun had done that I ascribed to
incompetence were done because of some other factor I had not
considered. They were quite aware of the drawback and were just as
disturbed about it as I was. He described the politics within Sun of
competing needs. One of them is being careful not to freak out the JVM
licensees with too many changes. They did not want to scare them off.
That would have loomed big in the decision to do generics with type
erasure.
--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
| |
| Jan Thomä 2008-03-28, 8:17 am |
| Lew wrote:
> If you already have a Class<T> instance, you don't need a cover function
> for
> your one-line call to newInstance(). Now, if you were to encapsulate the
> error-handling in that one-liner, it very likely is worth the cover
> function.
Indeed. My intent was to show that one way of doing it is to force the users
of your class to supply you with a Class<T> if you really need to
instanciate a T in your class. Of course you don't need the wrapper. I'll
try to be more clear next time.Thanks for the hint ;)
Jan
--
________________________________________
_________________________________
insOMnia - We never sleep...
http://www.insOMnia-hq.de
| |
| Mark Space 2008-03-28, 7:31 pm |
| Jan Thomä wrote:
> Mark Space wrote:
>
> Well they did that in Dot.Net which introduced a lot of headaches because
> you could no longer use libraries that used untyped collections together
> with typed collections. So if you wanted to use a library that was still
This is a good point. Lately I've been advocating some sort of
annotation that would give the compiler a hint for it to generate
boilerplate.
Try to do that on one's own runs into two problems:
1. Not everyone is going to implement their own API in the same way. So
non-standard and diverse implementations make it harder on the programmer.
2. The Class class is final, and can't be extended for a new class type
or new methods. If Sun would add a new type, or a some new methods to
Class, to support a type with reifiable types, again folks would not
have to come up with their own non-standard solutions.
I think just adding boilerplate to the existing classes would keep
backwards compatibility. The Class issue might be harder, but if the
new class type is only available through new interfaces, then I think
computability issues will be kept to a minimum.
|
|
|
|