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 <asta...@gmx.de> 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.
teso...@gmail.com
