Iâm playing again with Talents and I want that in Pharo8 to appear so it can mature. I want to discuss a few things Iâm not clear about in order to help steering the talents in the right direction. I think Talents do not properly separate concerns. If you add a talent to an object each object gets its own anonymous class with its own method dictionary. To me this is two things at the same time. One use case I want is âruntime traitsâ. It means that you can add a trait at runtime to an object which acquires the functionality. But all objects of the same class + talent should share the same anonymous subclass. This would be possible in a performant way if I only want behavioral flexibility. It is just one more class per use case. A second step is âobject-centric behaviourâ which finally privatizes the method dictionary to one object making object-centric logging/debugging/⦠possible. This is somewhat expensive but for object centric logging/debugging/⦠there will be only a small amount of objects being extended. With Traits and now with Talents we need to rethink parts of the reflection API. We have #isKindOf: and #includesBehavior: which are not properly aligned at the moment [1] and for talents it gets even wrong. I think we need a definition what is a kind. What it means to include a behavior I find more straight forward. I used a few test classes Object subclass: #ContainsNoTrait instanceVariableNames: '' classVariableNames: '' package: 'Talents-Testâ Object subclass: #ContainsOneTrait uses: Doable instanceVariableNames: '' classVariableNames: '' package: 'Talents-Testâ Object subclass: #ContainsTwoTraits uses: Doable + Doable2 instanceVariableNames: '' classVariableNames: '' package: 'Talents-Testâ Trait named: #Doable uses: {} slots: { #status } package: 'Talents-Testâ Trait named: #Doable2 uses: {} slots: { #status2 } package: 'Talents-Testâ Code is attached. When I create instances of each noTrait := ContainsNoTrait new. oneTrait := ContainsOneTrait new. twoTraits := ContainsTwoTraits new. oneTalent := ContainsNoTrait new addTalent: Doable; yourself. twoTalents := ContainsNoTrait new addTalent: Doable + Doable2; yourself . and create a table of each behavior I get which doesnât look quite right. My opinion is that all of the #includesBehavior: calls should return true. Iâm not so sure about the #isKindOf: If we continue on that road the single class inheritance wonât be central to all of the code but a special quality. One of the composed elements can be a class with a superclass hierarchy. I donât know if there is a rationale that #includesBehavior: and #isKindOf: refer to that the same thing or not. It would be good to take the opportunity to make this a concept which gives back some symmetry again. Norbert [1] https://github.com/pharo-project/pharo/issues/3958 <https://github.com/pharo-project/pharo/issues/3958>
