[Pharo-project] Smells looking at collections

Stéphane Ducasse stephane.ducasse at inria.fr
Sun Oct 24 16:45:11 EDT 2010


>> 
>>> 
>>>> 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.
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. 

> 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





More information about the Pharo-dev mailing list