Sorry, I have missed them. That is why it is better to create a PR. I will check it. Cheers, On Thu, Aug 30, 2018 at 10:38 AM Torsten Bergmann <astares@gmx.de> wrote:

Hi Pablo,

were you able to have a look at my changeset with the fix provided in July already:

http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2018-July/272614....

I would like to get https://pharo.fogbugz.com/f/cases/22271/Fix-IndexedSlots-in-combination-with... fixed.

Thanks T.

*Gesendet:* Dienstag, 17. Juli 2018 um 12:51 Uhr *Von:* "Torsten Bergmann" <astares@gmx.de> *An:* pharo-dev@lists.pharo.org *Cc:* Pharo-dev <pharo-dev@lists.pharo.org> *Betreff:* Re: [Pharo-dev] IndexedSlots in combination with StatefulTraits 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.

-- Pablo Tesone. tesonep@gmail.com

tesonep@gmail.com 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

Hi 2018-07-17 9:55 GMT+01:00 tesonep@gmail.com <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.

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 <astares@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. tesonep@gmail.com