[Pharo-project] Smells looking at collections
siguctua at gmail.com
Sun Oct 24 22:46:22 EDT 2010
On 24 October 2010 23:45, Stéphane Ducasse <stephane.ducasse at inria.fr> wrote:
>>>>> 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.
> so can you explain what you meant because I did not understand it.
>>> 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.
> no this is not what I meant
>> 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.
> this is what we wanted to avoid.
Why? I think it having many benefits comparing to 'compiled once' idea.
We're slowly moving towards multiple environemnts, right?
So, what if i may want to use same trait in two different
environments, and one of its methods
using #Foo variable, which depending on environment could be one or
or be a classvar with different value.
It could be quite powerful thing for testing purposes. Suppose you
wanna test something against new implementation of old class.
Then you don't need to waste a time and replace Foo -> Bar, you just
need to put it in use in different environment,
where Foo implemented differently.
There are other things.. Suppose my class using different compiler
(#compilerClass). It means that any methods in class should be
compiled using that compiler. And trait methods should obey the same
rule without exception.
> Also because you may have to recompile all the other methods of the class hierarchy because if a trait add an instance
> variable then you should recompile the subclasses when a trait get added with a state in the superclass.
Yes, same as if you adding an extra ivar to existing class, which
Nothing really scary.
>> Instance variables should be used by name during compilation. If there's a name collision then use the instance variable map I mentioned above.
> what is that the instance variable map?
> take the time to write an example
>>> - 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.
> So indeed we could think about adding state.
>>>>> 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.
>>>>> 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.
>>> Pharo-project mailing list
>>> Pharo-project at lists.gforge.inria.fr
>> Pharo-project mailing list
>> Pharo-project at lists.gforge.inria.fr
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
Igor Stasenko AKA sig.
More information about the Pharo-dev