P8 + aTalent - aKind

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

P8 + aTalent - aKind

NorbertHartl
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






Bildschirmfoto 2019-07-23 um 11.10.54.png (276K) Download Attachment
Talents-Test.st (4K) Download Attachment
playground.st (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: P8 + aTalent - aKind

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


Norbert


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



<Talents-Test.st>
<playground.st>

Reply | Threaded
Open this post in threaded view
|

Re: P8 + aTalent - aKind

Sean P. DeNigris
Administrator
In reply to this post by NorbertHartl
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

Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: P8 + aTalent - aKind

tesonep@gmail.com
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, <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: P8 + aTalent - aKind

gcotelli
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 [hidden email] <[hidden email]> 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, <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: P8 + aTalent - aKind

Marcus Denker-4
In reply to this post by tesonep@gmail.com


> On 23 Jul 2019, at 18:04, [hidden email] 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