On Thu, Nov 6, 2008 at 1:49 PM, Jess Holle <[EMAIL PROTECTED]> wrote:
> Viktor Klang wrote:
>
> Actually guys, referential equality is kind of retarded, so the
>
> Map<String,Integer>.class == Map<Foo,Bar>.class
>
> example is bad.
>
> However,
>
> Map<String,Integer>.class.equals(Map<Foo,Bar>.class) SHOULD return false
>
> No, it MUST not -- else loads of things break.
>
If you want to make an omelet, you've got to break some eggs...
>
>
> Further == and .equals MUST give the same results for Class objects -- else
> loads of things break.
>
> The "ConcreteClass" noted below would not be a Class -- it would be a new
> API.
>
Yeah, I realize that, that's why I'm moving away from Java.
>
>
> --
> Jess Holle
>
> On Thu, Nov 6, 2008 at 12:38 AM, Jess Holle <[EMAIL PROTECTED]> wrote:
>
>> Peter Becker wrote:
>>
>> I think you probably want something like:
>>
>> Object -> ConcreteClass(String,Foo) -> GenericClass
>>
>> which adds the extra class instances, but they should be very small
>> and not too many.
>>
>> Alternatively you could do:
>>
>> Object(String,Foo) -> GenericClass
>>
>> but then you'd have to store the type parameters on each object, which
>> is probably much more expensive in total. The former approach seems to
>> also match the type model better.
>>
>>
>> Yes, I was thinking something along the lines of the former.
>>
>> On Thu, Nov 6, 2008 at 8:22 AM, Jess Holle <[EMAIL PROTECTED]> <[EMAIL
>> PROTECTED]> wrote:
>>
>>
>> Peter Becker wrote:
>>
>> Sorry: I missed that parameter in your method.
>>
>> Wouldn't adding this information lead to a potential explosion of
>> Class instances at runtime similar to C++ templates? OTOH: there are
>> only a limited number of type parameters you'd actually use in your
>> code, so it is probably not too bad -- after all we wouldn't copy the
>> whole code as C++ does, just get a construct refering to the generic
>> class version and storing the type parameters.
>>
>>
>> Avoding this explosion is a benefit of erasure as well. Dealing with C++ I
>> quickly had dozens and dozens of copies of the same (sizable) object code
>> all due to instantiation with different types -- even where the usage of the
>> types in question (e.g. char*, void*, int*, Foo*, etc, in a vector<>) ended
>> up being 100% equivalent from an object code perspective. I don't want to
>> go near that sort of issue again.
>>
>> That said, I see no reason to have separate Class objects for
>> Map<String,Foo> and Map<Bar,Baz>. This would lead to bloat and
>> incompatibility.
>>
>> Rather one could have something like a "GenericTypesMap", ala:
>>
>> For class Map<K,V>, Map<String,Foo> would have a GenericTypesMap of
>> {K->String,V->Foo}
>>
>> GenericTypesMap's could be shared across all instances which use the same
>> instantation types and be weakly referenced by them or some such.
>>
>> I'm clearly just throwing together a strawman here, but the idea is to have
>> a separate chunk of runtime data that spells out the generic types used by
>> an instance without (1) breaking of existing Class contracts, explicit or
>> implicit, (2) resulting in duplication of Class objects or other bloat, or
>> (3) breaking interoperability between new and old code.
>>
>> --
>> Jess Holle
>>
>> On Thu, Nov 6, 2008 at 7:47 AM, Jess Holle <[EMAIL PROTECTED]> <[EMAIL
>> PROTECTED]> wrote:
>>
>>
>> getTypeParameters() will tell you that Map<K,V> is parameterized by K and V
>> and if/how these are contrained by wildcards.
>>
>> It won't tell you that the Map passed to your method is a Map<String,Foo>,
>> though. Map.class covers the generic notion of Map<K,V> -- it knows nothing
>> about how a particular instance was parameterized and there's no such thing
>> as a Map<String,Foo>.class in terms of this being any different than
>> Map<K,V>.
>>
>> Peter Becker wrote:
>>
>> Like this:
>>
>> http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Class.html#getTypeParameters()
>>
>> <http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Class.html#getTypeParameters%28%29>
>>
>> ?
>>
>> Peter
>>
>> On Wed, Nov 5, 2008 at 2:35 PM, Jess Holle <[EMAIL PROTECTED]> <[EMAIL
>> PROTECTED]> wrote:
>>
>>
>> For the most part, Java 5 class files contain metadata indicating much of
>> what the source file indicated as far as generics are concerned. This is
>> certainly the case for field/method/class declarations. I'm not sure about
>> local variable declarations, though.
>>
>> That said, once one has something like:
>>
>> void <T extends Foo> sort( List<T> list ) { ... }
>>
>> one can only determine that 'list' is parameterized by 'T', any
>> extends/super constraints, etc. The body of sort() here has no other
>> notions about T -- either in the class file or at runtime. That is
>> erasure. List<A>.class == List<B>.class == List.class. This is necessary
>> to keep the existing contracts and is a key benefit to erasure -- both in
>> lack of class bloat and in preservation of existing contracts and
>> compatibility. One could potentially have a special
>> Class.getGenericTypeInfos(Object) utility that could seperately lookup this
>> info, e.g. by having each object refer to both its class and its generic
>> typing info -- rather than to just the class. When called by old,
>> non-generic-savvy code the generic typing info would be null, of course.
>> One could have the compiler do nifty bits with such a getGenericTypeInfos()
>> utility so that one could do things like "new T[]" in sort -- throwing a
>> runtime exception if the typing info is not present. This would be undoing
>> erasure without blowing new/old code interoperability except where actually
>> necessary.
>>
>> --
>> Jess Holle
>>
>> Christian Catchpole wrote:
>>
>> Here is my analysis of the situation. I could be wrong. But here
>> goes..
>>
>> When I got my copy of Java 5 my first question was, do generics really
>> take the cast out of the equation? I disassembled the code to find
>> the cast still exists. This implies that when you compile this..
>>
>> HashMap<String,String> map = new HashMap<String,String>()
>> String string = map.get("");
>>
>> The generated code actually equates to this..
>>
>> HashMap map = new HashMap()
>> String string = (String)map.get("");
>>
>> The class returned by map.getClass() does not know the map only
>> contains Strings. It's actually the reference to the map which
>> marshals the types.
>>
>> I did a quick test...
>>
>> HashMap<String,String> map1 = new HashMap<String,String>();
>> HashMap<Date,Date> map2 = new HashMap<Date,Date>();
>>
>> System.out.println(map1.getClass() == map2.getClass());
>>
>> true
>>
>> They use the same class and can't therefore hold the type information
>> for both declarations.
>>
>> I can only assume this re-compiler the posse were talking about, scans
>> the code for the actual cast / type check to determine the types.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
> --
> Viktor Klang
> Senior Systems Analyst
>
>
>
>
> >
>
--
Viktor Klang
Senior Systems Analyst
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
