i'm not on the user list right now so maybe you can forward... a couple of clarifications below...

   jonathan

On 3/27/06, Igor Vaynberg < [EMAIL PROTECTED]> wrote:
i cant speak for HLS and what he had in mind. the blog JL wrote was a musing on how to improve the java language itself by introducing an idea of a mixed-type.

the inheritance is defined by a "isa" relationship. so if A extends B - A isa B

with multiple inheritance you have
A extends B,C means A isa B AND A isa C

there are various problems that this introduces.

what JL described is a system where you can declare an instance as [A,B] obj=[new A(), new B()]

very close, but not quite.  it's an [A B] all right, but you can't mix any two types.  the mixable has to declare that it's mixable with the mixee interface or class through it's public API.  i also think i want to change the name from mixing to "enhancing" because mixing has a lot of connotations having to do with implementation inheritance or delegation.  what you're really doing is enhancing A with B like "B enhanced A".  in many cases, the new B() is implicit (if it has no parameters) and it attaches to the reference automatically so casting is not required on an [A B].  what's more enhancers can nest so you get layering effects.

where the object you get back can be cast to either A or B - so identical to having something like class C { public A, public B } and doing obj=new C(); C.a=new A(); C.b=new B() - but supported natively on the jvm level w/out the overhead and obvious casting benefits.

take a concrete example. wicket Component and MetaData object

currently Components can carry metadata, but not necessarily every component carries it. But in order for some to carry it we have to declare it in Component so it adds overhead for those componetns that do not. Also MetaData can be a self contained object with reusable methods such as addMetaData(key, value).

so if we had mixed types we could take MetaData and separate it out of the Component. If a component you were instantiating needed metadata you would declare it as such:

Component c=new Component() mixes new MetaData();

yeah, but what i'm suggesting is actually "MetaData enhanced Component c = new Component()"
since MetaData doesn't require any parameters to enhance Component, there's nothing else on the new side of the assignment.  the metadata is just added once the component is created. 

so now you have c which isa Component but is/not/ MetaData; however, you can also cast it to medata:
MetaData md=(MetaData)c;

no, it IS a MetaData too.  you would get IDE support for completions directly from the "c" local variable!

c.setMetaData(...) would work because the reference c is actually an enhanced type reference.

you can also declare functions as wanting a mixed type: foo([A,B] obj);

you could but that would be fairly rare.  the syntax would be foo(B enhanced A obj) if you really wanted
something that was both...  btw, type enhancers can be added to classes as well as declared so you could
use MetaData as a kind of delayed mixin where it's not actually accessible in the mixee.

this would require jvm and tooling support to be easy to use and of course w/out tooling support you would lose some typesafety.

it would require a new java major version.  no type safety would be lost.

this can be done to some degree using bytecode manipulation, but not without it being very ugly.

ugly and a combinatorial explosion if the reusability of this concept really caught on.  you need the vm to do this.

On 3/27/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
i cant speak for HLS and what he had in mind. the blog JL wrote was a musing on how to improve the java language itself by introducing an idea of a mixed-type.

the inheritance is defined by a "isa" relationship. so if A extends B - A isa B

with multiple inheritance you have
A extends B,C means A isa B AND A isa C

there are various problems that this introduces.

what JL described is a system where you can declare an instance as [A,B] obj=[new A(), new B()]

where the object you get back can be cast to either A or B - so identical to having something like class C { public A, public B } and doing obj=new C(); C.a=new A(); C.b=new B() - but supported natively on the jvm level w/out the overhead and obvious casting benefits.

take a concrete example. wicket Component and MetaData object

currently Components can carry metadata, but not necessarily every component carries it. But in order for some to carry it we have to declare it in Component so it adds overhead for those componetns that do not. Also MetaData can be a self contained object with reusable methods such as addMetaData(key, value).

so if we had mixed types we could take MetaData and separate it out of the Component. If a component you were instantiating needed metadata you would declare it as such:

Component c=new Component() mixes new MetaData();

so now you have c which isa Component but is/not/ MetaData; however, you can also cast it to medata:
MetaData md=(MetaData)c;

you can also declare functions as wanting a mixed type: foo([A,B] obj);

this would require jvm and tooling support to be easy to use and of course w/out tooling support you would lose some typesafety.

this can be done to some degree using bytecode manipulation, but not without it being very ugly.

if you have more questions on mixed-types please ask on JL's blog, im sure he will be happy to explain.

-Igor



On 3/27/06, ali < [EMAIL PROTECTED]> wrote:
On Sat, 25 Mar 2006 09:47:02 +0530, Eelco Hillenius
<[EMAIL PROTECTED]> wrote:

> FYI, Matt Raible asked me to give my opinion about Wicket and some of
> it's competitors. He presenting it tonight at the server side
> symposium, and you can find his presentation here:
> http://www.virtuas.com/articles/webframework-sweetspots.html
>
> Eelco
>


Tapestry

4. What is the future of your web framework? What?s coming that?ll make it
easier for users to develop with? Do you support Ajax natively? If not,
are you planning on adding support?

Tapestry 4.0 has very good Ajax support via the Tacos library. Tapestry
4.1 will make a number of internal API changes to make that support even
better.

Tapestry 5 will be significantly advanced over Tapestry 4 or anything
else; planned features
are

? No more abstract classes.
? No inheritance imposition.
? Annotations directly on fields rather than on (abstract) methods.
? No XML, just templates and annotations.
? Smart class loader; pick up changes to classes automatically and
efficiently.
? Minimal APIs, beyond annotations.
? Aspect-oriented construction of components, using mix-ins.<<<<<<<

i see post <a
href="" href="http://jroller.com/page/JonathanLocke?entry=mixed_types_and_wicket" target="_blank" > http://jroller.com/page/JonathanLocke?entry=mixed_types_and_wicket>Mixed
Types and Wicket</a> of JonathanLocke , now see Howard Lewis Ship also
speak about same topic. it's seem topic is important

can every one speak about this in wicket ?
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user


Reply via email to