Re: [Pharo-dev] P8 + aTalent - aKind

July 23, 2019

      Just if you wonder where this #includesTalent: method is. You can get it from here

https://github.com/noha/pharo-talents/tree/api-enhancements <https://github.com/noha/pharo-talents/tree/api-enhancements>

Norbert
...
Am 23.07.2019 um 11:24 schrieb Norbert Hartl <norbert@hartl.name>:
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
<Bildschirmfoto 2019-07-23 um 11.10.54.png>
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>
<Talents-Test.st>
<playground.st>