Stateful traits (was Re: [ANN] Open meeting regarding the Squeak Release Team)

On Feb 9, 2008 9:17 PM, stephane ducasse <[hidden email]> wrote:
I didn't intend to imply anything like that.  I was just curious about
the fundamental difference.  The terminology is obviously different,
but for me data+methods is an object what ever it's called.  In that
context stateful traits seemed like MI with everything outside the
main inheritance line named differently.

Of course you probably deal with conflicts differently then existing
MI systems, and there should probably be more research done on MI.
C++ did an awful job of it, but I've heard good things about Lisp
CLOS.  In C++ one can potentially have very deep (unnaturally so)
class hierarchies due to pressure from the type system but neither
Smalltalk nor Lisp have that problem.

>
> I didn't intend to imply anything like that.

I know but I just wanted to make that point clear. :)

> I was just curious about
> the fundamental difference.  The terminology is obviously different,
> but for me data+methods is an object what ever it's called.  In that
> context stateful traits seemed like MI with everything outside the
> main inheritance line named differently.

The main difference is that traits give control to the composer.

> Of course you probably deal with conflicts differently then existing
> MI systems, and there should probably be more research done on MI.

Exact. The problem is that the more I think about it the more I thikn  
MI is difficult :)

> C++ did an awful job of it, but I've heard good things about Lisp
> CLOS.

In my previous live I was a Closer and Moper there. You get problem  
with linearisation
even if C3 as in dylan is better than the default CLOS one.

>  In C++ one can potentially have very deep (unnaturally so)
> class hierarchies due to pressure from the type system but neither
> Smalltalk nor Lisp have that problem.

In Clos you could have really strange unexpected beahvior where a  
change in one class
shows up in anoter place because of the linearisation. At least the  
people of nichimen (guys behind
Lord of the ring 3d engine) told me that problem when they wanted to  
hire me back in 1995.

Stef

On 11/02/2008, stephane ducasse <[hidden email]> wrote:

> Exact. The problem is that the more I think about it the more I thikn
> MI is difficult :)

And useless, in 99% of real world cases ;)



--
Best regards,
Igor Stasenko AKA sig.

Hi,

Igor Stasenko wrote:
> On 11/02/2008, stephane ducasse <[hidden email]> wrote:
>
>> Exact. The problem is that the more I think about it the more I thikn
>> MI is difficult :)
>
> And useless, in 99% of real world cases ;)
>
In a current project unfortunately forced to be in Java, we use Qt Jambi as
user interface library. To use the Qt 2D-Drawing facilities, you have to
inherit
from them. But of course, our database model shall not include these
data and has its own inheritance graph, thus due to single inheritance
in Java, we ended up with duplicated hierachy trees: One for the
database model, one for the Qt-2D-Items.

public class Event {...}
public class RoadEvent extends Event {...}

public class EventItem extends QGraphicsItem { Event mappedEvent; ...}
public class RoadEventItem extends EventItem {...}

This is simply not beautiful. There exist Qt Jambi interfaces to
circumvent this, but then the code of QGraphicsItem needs to
reimplemented, because interfaces don't have implementation on their own.

Btw, did anyone think of something like QTSqueak yet? What happend to
wxsqueak?

Regards,
Martin