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

[Marcus Denker]

> On 23 Jul 2019, at 18:04, teso...@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

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

[Gabriel Cotelli]

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 teso...@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, 
> 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
>>
>>

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

[teso...@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,  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
>
>

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

[Sean P. DeNigris]

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

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

[Norbert Hartl]

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

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


Norbert


> Am 23.07.2019 um 11:24 schrieb Norbert Hartl :
> 
> 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 
> 
> 
> 
>