On Sun, 24 Oct 2010, Stéphane Ducasse wrote:
Not trivial? Maybe not, but only a little bit harder than trivial.
We are open to suggestions believe me :)
2) well, this is difficult to get the money for the butter and the butter - we
are trying.
If you can compose classes the way you can add a trait to a class now with
class and optional method level instance+class variable mapping, then you're
done. It would be a lot simpler to use it _and_ it would also be a lot easier
to implement it. Especially the tools part.
I'm interested to hear more about that.
Tell us more. The problem we faced was
- offset access = you cannot reuse bytecode of a trait because the
order of the offset can be different in each trait users
If you mean that a CompiledMethod of a trait cannot be added to the
class' method dictionary, than that's not an issue. The current Trait
implementation was changed, because shared CompiledMethods caused other
problems.
If you mean that the same bytecodes can't be used, than that's neither a
problem, because you can and should be compile the method again. Sharing
trailer bytes may cause problems.
So adding a method from a trait to a class is simply recompiling it in the
class' context. Instance variables should be used by name during
compilation. If there's a name collision then use the instance variable
map I mentioned above.
- initialization of instances variables at the trait level and the
composition at the class levele
You can always rename a trait's method in your class. So if the trait has
an #initialize method, then simply rename it to #initializeFooBar and send
it from the class' #initialize method.
Levente
3) again if nobody does anything and we just all cry on ourselves then nothing
will happen.
Tools are a must. No tools - no users.
Exact.
So for now identifying traits and learning is the way. Then we can refactor,
redesign
Well, Traits are in Squeak since 2006, IIRC they were available a few years
earlier. So in the last X (at least 4) years the only good candidate to become
a Trait was Magnitude.
Come on.
I will not answer to such statement because I'm positive thinking.
Stef
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
