[Pharo-project] Smells looking at collections

Igor Stasenko 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
another class,
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
having subclasses.
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.
>
> Yes this is what the javascript implementation does but this is not that nice but may be there is no better solution.
>
> So indeed we could think about adding state.
>
>
>
>>
>>
>> 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
>>> Pharo-project at lists.gforge.inria.fr
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>> _______________________________________________
>> Pharo-project mailing list
>> Pharo-project at lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



-- 
Best regards,
Igor Stasenko AKA sig.




More information about the Pharo-dev mailing list