polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: Generic composite types in Zest
Date Fri, 18 Dec 2015 01:40:39 GMT
In Zest Java, there is limited support for generic types. For instance,

    Foo<Long> longFoo;

    Foo<String> stringFoo;

is handled as expected.

To sort out what Java can and can not do;
As you mention, Java's generics support is not complete, but it is (and
always been) incorrect (despite everyone saying so) that the generics are
compile-time only.

The "declaration" of something (method return type, method parameters,
fields,...) all has the generics information in them, even the TypeVariable
name ("K" and "V" in Map<K,V>). But the object doesn't reference the
ParameterizedType (only the Class) instance, so that bit is missing (still,
and probably not going to be fixed).

This has some consequences,

    Object list = new ArrayList();   // local variable = No generics
    abc( list );   // Requires cast, but only for compiler. No runtime
check possible
    def( list );    // Requires cast, but only for compiler. No runtime
check possible

public void abc( List<String> list ) {}
public void def( List<Long> list ) {}

So, from there it is possible to fill the List with any type you want. So,
there is no possibility to equal()=false for

    new ArrayList<Long>().equals( new ArrayList<String>() )

the information isn't there.

Now, this also means that;

    ValueBuilderFactory vbf;

    MyValueComposite<String> v =
        (MyValueComposite<String>) vbf.newValue( MyComposite.class);

will "work" just as well as the java.util.List shown above.

So beyond these basic two cases, I am not sure what else can be done to
support Generic Types in Zest Java.

I am uncertain whether nested generics works for Services;

    Foo<Map<String, Map<Long, Bar>>> foo;

But that would be the only thing that I could imagine to be improved.

Other concrete ideas are welcome.


On Thu, Dec 17, 2015 at 10:33 PM, Stanislav Muhametsin <
stanislav.muhametsin@zest.mail.kapsi.fi> wrote:

> This thing came to my mind when writing previous mail about Assemblies,
> Models, and Instances.
> Is it true that Zest still has limitation/restriction not to support
> generic composites (i.e. MyComposite<T, U> -interfaces as composite types)?
> IMO you might want to remove that limitation.
> I am not sure if that is possible, since generics in Java exist only at
> compile-time (is this so with newest Java?).
> But I am certain that many people are most likely to give up on Zest when
> they encounter that limitation (I know it was a tough slap-in-the-face for
> me, when I encountered it).
> If you decide to remove this limitation, I could give some pointers as to
> which pitfalls to avoid, and what to keep in mind, when dealing with
> generic composite types.
> I encountered a lot of trouble when I implemented generic composites in
> Qi4CS, but the type system in CLR preserves generic argument information at
> runtime (so, in Java terms, that List<String>.class will return *false*
> when doing equality comparison with List<Int32>.class), so it was possible
> to implement support for generic composite types.
> In Zest, it might make code generation more complex, and it might make the
> method intercepting code in Zest more complex, but I think it is worth the
> hassle.

Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message