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>
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>
NorbertHartl wrote
Iâm playing again with Talents and I want that in Pharo8 to appear so it can mature.
I'm very interested in this. Adding behavior at runtime only when an object takes on a role seems to have many possibilities e.g. expressiveness and code simplification. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
Hi Norbert, I share the point of improving the implementation to reuse the anonymous classes. I will check that and propose a solution, of course if any one else want to propose something is welcomed. Thinking about the reflective messages I don't have a stablished opinion. I think the behaviour should be the most similar to the one of traits, and avoiding custom messages. So, what I am saying that I am tempted to review all the api (classes, traits, talents... What ever somebody invents). I would love to get more opinions On Tue, 23 Jul 2019, 16:51 Sean P. DeNigris, <sean@clipperadams.com> wrote:
NorbertHartl wrote
Iâm playing again with Talents and I want that in Pharo8 to appear so it can mature.
I'm very interested in this. Adding behavior at runtime only when an object takes on a role seems to have many possibilities e.g. expressiveness and code simplification.
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
I'm also interested in discussing about the meta object protocol. Maybe we can coordinate something during the ESUG? On Tue, Jul 23, 2019, 13:04 tesonep@gmail.com <tesonep@gmail.com> wrote:
Hi Norbert, I share the point of improving the implementation to reuse the anonymous classes. I will check that and propose a solution, of course if any one else want to propose something is welcomed.
Thinking about the reflective messages I don't have a stablished opinion. I think the behaviour should be the most similar to the one of traits, and avoiding custom messages. So, what I am saying that I am tempted to review all the api (classes, traits, talents... What ever somebody invents). I would love to get more opinions
On Tue, 23 Jul 2019, 16:51 Sean P. DeNigris, <sean@clipperadams.com> wrote:
NorbertHartl wrote
Iâm playing again with Talents and I want that in Pharo8 to appear so it can mature.
I'm very interested in this. Adding behavior at runtime only when an object takes on a role seems to have many possibilities e.g. expressiveness and code simplification.
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
On 23 Jul 2019, at 18:04, tesonep@gmail.com wrote:
Hi Norbert, I share the point of improving the implementation to reuse the anonymous classes. I will check that and propose a solution, of course if any one else want to propose something is welcomed.
Another client for anonymous classes will be Object Specific MetaLinks⦠we need to find some way that if you install a link on a method on an object that has a Talent, that the methinks re-use that anonymous class, too. Marcus
participants (5)
-
Gabriel Cotelli -
Marcus Denker -
Norbert Hartl -
Sean P. DeNigris -
tesonep＠gmail.com