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