Dale
I missed your remark about traits.I think that traits are nice because
they act as a kind of static macro expansion and really help to get
multiple inheritance into single one.
Now ideally I would like to have
(I hate so much this google nonUI)
- state with traits with a nice initialization process.
- Now Pablo did a nice and simple implementation of Talents (dynamic
traits). I should have a look because if we could unify it and have
either a trait statically applied to a class (what we have now) and a
trait being applicable to an instance then it would be really good.
Now making the tools traits-aware is much more than just having traits in
the language.
- change
- loading
- editing
- overloading when we compile a method that comes from a trait we
should be able to say that it overrides.....
What we did with the "unification" of traits and classes and the use of
traits inside the kernel is a mistake (in Squeak andreas if I recall made
Trait a subclass of classDescription
and this is not good either - even if he marketed it as a good idea) and
we will iterated to remove the use of traits from Class and friends.
Then ideally I would like to iterate over the
- reflective API (because we should be able to simply access the
"class" of a compiledMethod from where the traits is coming from or where
it is installed
- revisite the implementation because the clause composition.
I think that the tools should not manipulate traits as classes because
traits are not classes.Then doing this we will clarify that the traits
and classes must not be polymorphic because they are not.
Stef,
Thanks for the clarification ... we are open to adding traits to
GemStone and perhaps we should talk a little bit more about your ideas
on a "better implementation" ... at this point GemStone 3.5 >would be
the target version and that would give us time for syncing up the
implementation.
Sure.
This can be a good incentive for us to revisit it.
Stef
