IndexedSlots in combination with StatefulTraits

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

IndexedSlots in combination with StatefulTraits

Torsten Bergmann
I guess I found a bug in accessing Slots using #slots in combination with IndexedSlots and traits.
To reproduce use latest Pharo 7 (Build 1126)

First create a class with a slot, note that the slot needs to be :

Object subclass: #ClassA
        slots: { IndexedSlot named: #upper }
        classVariables: { }
        package: 'Slot-Bugs'

As it is the first slot it internally receives an index 1 as you can check with "ClassA slots first".

Now define a stateful trait with another indexed slot:
       
        Trait named: #StatefulTrait
                uses: {}
                slots: { IndexedSlot named: #slotFromTrait }
                category: 'Slot-Bugs'
         
And create a new subclass using the new Trait

        ClassA subclass: #ClassB
                uses: StatefulTrait
                instanceVariableNames: ''
                classVariableNames: ''
                package: 'Slot-Bugs'
         

1. when you evaluate "ClassA slots"  it returns {#FirstSlot => Slot} which is correct
2. when you evaluate "StatefulTrait slots"  it returns {#slotFromTrait => Slot} which is correct
3. when you evaluate "ClassB allSlots"  returns  "an OrderedCollection(#upper => InstanceVariableSlot #slotFromTrait => InstanceVariableSlot)" which is OK

but  

4. when you evaluate "ClassB slots" it returns  {#slotFromTrait => InstanceVariableSlot} which is NOT correct as class B does not define the slot, it is defined in the trait

         
So I think 4. is wrong and reasons is the implementation of #slot:

  slots
        "I remove the slots comming from a traitComposition"
        ^ super slots reject:[ :e  | self traitComposition slots includes:e ]
       
If you debug you will notice that

   super slots                   returns our #slotFromTrait with an index of 2 while
   self traitComposition slots   returns our #slotFromTrait with an index of 1 while

which is the same #slotFromTrait but a different index - therefore it does not get removed.

 
Dont know what is the best way to fix this without any side effects. Commenst and help appreciated.

Thanks
T.

Reply | Threaded
Open this post in threaded view
|

Re: IndexedSlots in combination with StatefulTraits

tesonep@gmail.com
Hi Torsten, 
   the problem is defining the behavior expected from the set of messages:

Today we have 3 (yes 3.... awful) they are to keep compatibility with the tools, we have to continue improving them.

- allSlots: returns all the slots defined in the hierarchy, in the same class and in all the traits used in the hierarchy.
- localSlots: returns the slots that are defined in the own class without the ones in the traits.
- slots: returns the slots that are defined in the class and not in the superclasses.

The last message is the one that is disturbing, it is kept for compatibility with the old behavior. In my opinion, localSlots should be removed, and slots behave like localSlots. 
It requires to change the tools. 

If we need to know where the slots are defined we can ask the slots, the slots know which is the class using the slot and where it is defined. 

So, I will like to improve in any way. 
About the implementation I like the one in #localSlots.
But it requires some work or letting the stuff broken until we fix them.

Cheers,
Pablo

On Tue, Jul 17, 2018 at 10:19 AM Torsten Bergmann <[hidden email]> wrote:
I guess I found a bug in accessing Slots using #slots in combination with IndexedSlots and traits.
To reproduce use latest Pharo 7 (Build 1126)

First create a class with a slot, note that the slot needs to be :

Object subclass: #ClassA
        slots: { IndexedSlot named: #upper }
        classVariables: { }
        package: 'Slot-Bugs'

As it is the first slot it internally receives an index 1 as you can check with "ClassA slots first".

Now define a stateful trait with another indexed slot:

        Trait named: #StatefulTrait
                uses: {}
                slots: { IndexedSlot named: #slotFromTrait }
                category: 'Slot-Bugs'   

And create a new subclass using the new Trait

        ClassA subclass: #ClassB
                uses: StatefulTrait
                instanceVariableNames: ''
                classVariableNames: ''
                package: 'Slot-Bugs'     


1. when you evaluate "ClassA slots"  it returns {#FirstSlot => Slot} which is correct
2. when you evaluate "StatefulTrait slots"  it returns {#slotFromTrait => Slot} which is correct
3. when you evaluate "ClassB allSlots"  returns  "an OrderedCollection(#upper => InstanceVariableSlot #slotFromTrait => InstanceVariableSlot)" which is OK

but 

4. when you evaluate "ClassB slots" it returns  {#slotFromTrait => InstanceVariableSlot} which is NOT correct as class B does not define the slot, it is defined in the trait


So I think 4. is wrong and reasons is the implementation of #slot:

  slots
        "I remove the slots comming from a traitComposition"
        ^ super slots reject:[ :e  | self traitComposition slots includes:e ]   

If you debug you will notice that

   super slots                   returns our #slotFromTrait with an index of 2 while
   self traitComposition slots   returns our #slotFromTrait with an index of 1 while

which is the same #slotFromTrait but a different index - therefore it does not get removed.


Dont know what is the best way to fix this without any side effects. Commenst and help appreciated.

Thanks
T.



--
Pablo Tesone.
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: IndexedSlots in combination with StatefulTraits

Torsten Bergmann
Hi Pablo,
 
thanks for the quick answer. The attached CS would fix it ... can you have a review so we can open a bug and do a PR?

Then at least this could be integrated independent from when the tools and traits are cleaned up.

Thanks
T.

FixIndexSlottedTraits.cs (989 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: IndexedSlots in combination with StatefulTraits

Sean P. DeNigris
Administrator
In reply to this post by tesonep@gmail.com
[hidden email] wrote
> the one that is disturbing, it is kept for
> compatibility with the old behavior

Are there enough users to justify backward compatibility if it costs a nice
API?



-----
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

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

Re: IndexedSlots in combination with StatefulTraits

Denis Kudriashov
In reply to this post by tesonep@gmail.com
Hi

2018-07-17 9:55 GMT+01:00 [hidden email] <[hidden email]>:
Hi Torsten, 
   the problem is defining the behavior expected from the set of messages:

Today we have 3 (yes 3.... awful) they are to keep compatibility with the tools, we have to continue improving them.

- allSlots: returns all the slots defined in the hierarchy, in the same class and in all the traits used in the hierarchy.
- localSlots: returns the slots that are defined in the own class without the ones in the traits.
- slots: returns the slots that are defined in the class and not in the superclasses.

The last message is the one that is disturbing, it is kept for compatibility with the old behavior. In my opinion, localSlots should be removed, and slots behave like localSlots. 

Would be nice to have it consistent with #methods and #localMethods.
I would prefer explicit names like definedSlots, owningSlots (if needed). And same for methods.
 
It requires to change the tools. 

If we need to know where the slots are defined we can ask the slots, the slots know which is the class using the slot and where it is defined. 

So, I will like to improve in any way. 
About the implementation I like the one in #localSlots.
But it requires some work or letting the stuff broken until we fix them.

Cheers,
Pablo

On Tue, Jul 17, 2018 at 10:19 AM Torsten Bergmann <[hidden email]> wrote:
I guess I found a bug in accessing Slots using #slots in combination with IndexedSlots and traits.
To reproduce use latest Pharo 7 (Build 1126)

First create a class with a slot, note that the slot needs to be :

Object subclass: #ClassA
        slots: { IndexedSlot named: #upper }
        classVariables: { }
        package: 'Slot-Bugs'

As it is the first slot it internally receives an index 1 as you can check with "ClassA slots first".

Now define a stateful trait with another indexed slot:

        Trait named: #StatefulTrait
                uses: {}
                slots: { IndexedSlot named: #slotFromTrait }
                category: 'Slot-Bugs'   

And create a new subclass using the new Trait

        ClassA subclass: #ClassB
                uses: StatefulTrait
                instanceVariableNames: ''
                classVariableNames: ''
                package: 'Slot-Bugs'     


1. when you evaluate "ClassA slots"  it returns {#FirstSlot => Slot} which is correct
2. when you evaluate "StatefulTrait slots"  it returns {#slotFromTrait => Slot} which is correct
3. when you evaluate "ClassB allSlots"  returns  "an OrderedCollection(#upper => InstanceVariableSlot #slotFromTrait => InstanceVariableSlot)" which is OK

but 

4. when you evaluate "ClassB slots" it returns  {#slotFromTrait => InstanceVariableSlot} which is NOT correct as class B does not define the slot, it is defined in the trait


So I think 4. is wrong and reasons is the implementation of #slot:

  slots
        "I remove the slots comming from a traitComposition"
        ^ super slots reject:[ :e  | self traitComposition slots includes:e ]   

If you debug you will notice that

   super slots                   returns our #slotFromTrait with an index of 2 while
   self traitComposition slots   returns our #slotFromTrait with an index of 1 while

which is the same #slotFromTrait but a different index - therefore it does not get removed.


Dont know what is the best way to fix this without any side effects. Commenst and help appreciated.

Thanks
T.



--
Pablo Tesone.
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: IndexedSlots in combination with StatefulTraits

Pharo Smalltalk Developers mailing list
In reply to this post by Sean P. DeNigris
The Slot class implementation is fundamentally sound but the larger constructs surrounding Frames and Slots still requires extensive thought.

I suspect that you will find that many more changes will be discovered as work is done with it.

Slots provide the capacity to implement most of AOP concepts in a simple manner. It also results in a Frame model.

I also would suggest careful examination of when to use composition versus traits with slots.

Regards

Reg Krock


> On 17 Jul2018, at 1:44 PM, Sean P. DeNigris <[hidden email]> wrote:
>
> [hidden email] wrote
>> the one that is disturbing, it is kept for
>> compatibility with the old behavior
>
> Are there enough users to justify backward compatibility if it costs a nice
> API?
>
>
>
> -----
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>


Reply | Threaded
Open this post in threaded view
|

Re: IndexedSlots in combination with StatefulTraits

Damien Pollet
I understand what slots are, but haven't heard of frames in this context… can you elaborate ?

On Wed, 18 Jul 2018 at 13:44, Reg Krock via Pharo-dev <[hidden email]> wrote:
The Slot class implementation is fundamentally sound but the larger constructs surrounding Frames and Slots still requires extensive thought.

I suspect that you will find that many more changes will be discovered as work is done with it.

Slots provide the capacity to implement most of AOP concepts in a simple manner. It also results in a Frame model.

I also would suggest careful examination of when to use composition versus traits with slots.

Regards

Reg Krock


> On 17 Jul2018, at 1:44 PM, Sean P. DeNigris <[hidden email]> wrote:
>
> [hidden email] wrote
>> the one that is disturbing, it is kept for
>> compatibility with the old behavior
>
> Are there enough users to justify backward compatibility if it costs a nice
> API?
>
>
>
> -----
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>




--
Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet
Reply | Threaded
Open this post in threaded view
|

Re: IndexedSlots in combination with StatefulTraits

NorbertHartl


Am 18.07.2018 um 14:39 schrieb Damien Pollet <[hidden email]>:

I understand what slots are, but haven't heard of frames in this context… can you elaborate ?

+1

Norbert
On Wed, 18 Jul 2018 at 13:44, Reg Krock via Pharo-dev <[hidden email]> wrote:
The Slot class implementation is fundamentally sound but the larger constructs surrounding Frames and Slots still requires extensive thought.

I suspect that you will find that many more changes will be discovered as work is done with it.

Slots provide the capacity to implement most of AOP concepts in a simple manner. It also results in a Frame model. 

I also would suggest careful examination of when to use composition versus traits with slots.

Regards

Reg Krock


> On 17 Jul2018, at 1:44 PM, Sean P. DeNigris <[hidden email]> wrote:
> 
> [hidden email] wrote
>> the one that is disturbing, it is kept for
>> compatibility with the old behavior
> 
> Are there enough users to justify backward compatibility if it costs a nice
> API?
> 
> 
> 
> -----
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
> 




-- 
Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet

Reply | Threaded
Open this post in threaded view
|

Re: IndexedSlots in combination with StatefulTraits

Pharo Smalltalk Developers mailing list
In reply to this post by Damien Pollet
Hi Damien,

Frames and Slots come from the AI world. The terms were defined by Marvin Minsky in his paper "A Framework for Representing Knowledge", Marvin Minsky, MIT-AI Laboratory Memo 306, June, 1974. ( https://web.media.mit.edu/~minsky/papers/Frames/frames.html).

Minsky realized that the AI world was looking at ‘intelligence’ from a perspective of small pieces. He challenges the AI world to start looking at things in a bigger picture. One of his example’s is a chair. He believed we have a ‘Frame’ which is the general shape of a chair. The Chair frame has ‘slots’ which represent details of the chair. The contents of a slot can be another ‘frame’.

In Smalltalk the Frame is analogous to a Class and a slot is somewhat analogous to an instance variable.

A key paper which describes the implementation of frames and slots in the AI world is: "The Design Space of Frame Knowledge Representation Systems” by Peter Karp. ( https://www.sri.com/work/publications/design-space-frame-knowledge-representation-systems ).

These are both old papers but they will give you the essence of what Frames and Slots from the AI world. In the 90’s there work done on the development of frame systems in Smalltalk. There are several very large Frame and Slot systems still in production.

I hope this helps.

Regards,

Reg

 

On 18 Jul2018, at 8:39 AM, Damien Pollet <[hidden email]> wrote:

I understand what slots are, but haven't heard of frames in this context… can you elaborate ?

On Wed, 18 Jul 2018 at 13:44, Reg Krock via Pharo-dev <[hidden email]> wrote:
The Slot class implementation is fundamentally sound but the larger constructs surrounding Frames and Slots still requires extensive thought.

I suspect that you will find that many more changes will be discovered as work is done with it.

Slots provide the capacity to implement most of AOP concepts in a simple manner. It also results in a Frame model. 

I also would suggest careful examination of when to use composition versus traits with slots.

Regards

Reg Krock


> On 17 Jul2018, at 1:44 PM, Sean P. DeNigris <[hidden email]> wrote:
> 
> [hidden email] wrote
>> the one that is disturbing, it is kept for
>> compatibility with the old behavior
> 
> Are there enough users to justify backward compatibility if it costs a nice
> API?
> 
> 
> 
> -----
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
> 




-- 
Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet