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