P8 + aTalent - aKind

Am 23.07.2019 um 11:24 schrieb Norbert Hartl <[hidden email]>:

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

<Talents-Test.st>

<playground.st>