Smalltalk › Squeak › Squeak - Dev

SequenceableCollection #= method in current trunk differs from Squeak 5.2

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

18 messages Options

Nikolay Suslov

SequenceableCollection #= method in current trunk differs from Squeak 5.2

Hello all,

Figuring out, could we go back to the previous version of SequenceableCollection #= method (as in Squeak 5.2), to check if the receiver is equivalent to the otherCollection by using "self species == otherCollection species", instead of "self class = otherCollection class"?

The current version of #= method breaks code in different places. For example the RFB/VNC server gives wrong results starting from an authentication process, where RFBMessage is the ByteArray subclass and implements #species.

Best regards,

Nikolai

Levente Uzonyi

Re: SequenceableCollection #= method in current trunk differs from Squeak 5.2

Hi Nikolai,

On Mon, 29 Jun 2020, Nikolay Suslov wrote:

> Hello all,
> Figuring out, could we go back to the previous version of SequenceableCollection #= method (as in Squeak 5.2), to check if the receiver is equivalent to the otherCollection by using "self species == otherCollection species",
> instead of "self class = otherCollection class"?

IIRC there was a good reason for that change though I can't recall
what it was. I'm sure the mailing list remembers.

> The current version of #= method breaks code in different places. For example the RFB/VNC server gives wrong results starting from an authentication process, where RFBMessage is the ByteArray subclass and implements #species.

If you're looking for a fix, try this:
http://leves.web.elte.hu/squeak/RFB-ul.18.mcz

Levente

>
> Best regards,
> Nikolai
>
>

Nikolay Suslov

Re: SequenceableCollection #= method in current trunk differs from Squeak 5.2

Thanks Levente,

Yes, seems to be RFB/VNC from the SqueakSource-SqF project page is outdated (at least it is working in Squeak 5.2 and not in 5.3 and later). Your version works fine!

However, it is interesting what was the reason for that change just in SequenceableCollection #=. As Set, Bitset, SortedCollection etc. classes still use species comparison in #= (checking they have the same set of keys)?

Best regards,

Nikolai

On Mon, Jun 29, 2020 at 3:43 AM Levente Uzonyi <[hidden email]> wrote:

Hi Nikolai,

On Mon, 29 Jun 2020, Nikolay Suslov wrote:

> Hello all,
> Figuring out, could we go back to the previous version of SequenceableCollection #= method (as in Squeak 5.2), to check if the receiver is equivalent to the otherCollection by using "self species == otherCollection species",
> instead of "self class = otherCollection class"?

IIRC there was a good reason for that change though I can't recall
what it was. I'm sure the mailing list remembers.

> The current version of #= method breaks code in different places. For example the RFB/VNC server gives wrong results starting from an authentication process, where RFBMessage is the ByteArray subclass and implements #species.

If you're looking for a fix, try this:
http://leves.web.elte.hu/squeak/RFB-ul.18.mcz

Levente

>
> Best regards,
> Nikolai
>
>

Chris Muller-3

Re: SequenceableCollection #= method in current trunk differs from Squeak 5.2

Might be worth reopening this discussion. ANY dependencies on #class seem like a bad thing to me, especially while it's still an in-lined message. Below is the MC version that did it. Looks like the time to change this 19-year old core method went from "itch" to trunk in all but just a few hours...

________________

Name: Collections-nice.820
Author: nice
Time: 12 February 2019, 11:56:35.262017 pm
UUID: bb383133-067c-4133-987b-c481a7de69c7
Ancestors: Collections-ul.819, Collections-cbc.813

Definitively abandon SequenceableCollection equality tests based on equal species.

Old behaviour can still be obtained thru hasEqualElements: but the default is to not try to support such trans-class equality feature because it is much too complex.

Particularly Interval are no more equal to Arrays with same sequence. We can thus optimize hash a bit more and fix the old bugs of equa objects with different hashes. Merge Collections-cbc.813 for this and rehashAll in postscript.

There are not so many classes concerned by this change, mainly RunArray, Interval and LinkedList:

Collection withAllSubclasses select: [:e | [e basicNew species ~= e] on: Error do: [false]]
-> an OrderedCollection(WeakRegistry LinkedList Interval ByteCharacterSet CharacterSetComplement LazyCharacterSet WideCharacterSet ShortRunArray Semaphore Mutex TextLineInterval WeakArray Monitor MCVersionName ByteSymbol WideSymbol)

We will have to change the tests that rely on such equality.

On Mon, Jun 29, 2020 at 3:42 AM Nikolay Suslov <[hidden email]> wrote:

Thanks Levente,

Yes, seems to be RFB/VNC from the SqueakSource-SqF project page is outdated (at least it is working in Squeak 5.2 and not in 5.3 and later). Your version works fine!
However, it is interesting what was the reason for that change just in SequenceableCollection #=. As Set, Bitset, SortedCollection etc. classes still use species comparison in #= (checking they have the same set of keys)?

Best regards,
Nikolai

On Mon, Jun 29, 2020 at 3:43 AM Levente Uzonyi <[hidden email]> wrote:
Hi Nikolai,

On Mon, 29 Jun 2020, Nikolay Suslov wrote:

> Hello all,
> Figuring out, could we go back to the previous version of SequenceableCollection #= method (as in Squeak 5.2), to check if the receiver is equivalent to the otherCollection by using "self species == otherCollection species",
> instead of "self class = otherCollection class"?

IIRC there was a good reason for that change though I can't recall
what it was. I'm sure the mailing list remembers.

> The current version of #= method breaks code in different places. For example the RFB/VNC server gives wrong results starting from an authentication process, where RFBMessage is the ByteArray subclass and implements #species.

If you're looking for a fix, try this:
http://leves.web.elte.hu/squeak/RFB-ul.18.mcz

Levente

>
> Best regards,
> Nikolai
>
>

Levente Uzonyi

Re: SequenceableCollection #= method in current trunk differs from Squeak 5.2

On Tue, 30 Jun 2020, Chris Muller wrote:

> Might be worth reopening this discussion. ANY dependencies on #class seem like a bad thing to me, especially while it's still an in-lined message. Below is the MC version that did it. Looks like the time to change this

Using #class by default sounds correct to me. If some instances of
classes want to be equal to each other, they should handle that
themselves by overriding #=.
Using #species everywhere is just horrible.

> 19-year old core method went from "itch" to trunk in all but just a few hours...

How did you come to that conclusion?

Levente

> ________________
> Name: Collections-nice.820
> Author: nice
> Time: 12 February 2019, 11:56:35.262017 pm
> UUID: bb383133-067c-4133-987b-c481a7de69c7
> Ancestors: Collections-ul.819, Collections-cbc.813
>
> Definitively abandon SequenceableCollection equality tests based on equal species.
>
> Old behaviour can still be obtained thru hasEqualElements: but the default is to not try to support such trans-class equality feature because it is much too complex.
>
> Particularly Interval are no more equal to Arrays with same sequence. We can thus optimize hash a bit more and fix the old bugs of equa objects with different hashes. Merge Collections-cbc.813 for this and rehashAll in
> postscript.
>
> There are not so many classes concerned by this change, mainly RunArray, Interval and LinkedList:
>
> Collection withAllSubclasses select: [:e | [e basicNew species ~= e] on: Error do: [false]]
> -> an OrderedCollection(WeakRegistry LinkedList Interval ByteCharacterSet CharacterSetComplement LazyCharacterSet WideCharacterSet ShortRunArray Semaphore Mutex TextLineInterval WeakArray Monitor MCVersionName ByteSymbol
> WideSymbol)
>
> We will have to change the tests that rely on such equality.
>
> On Mon, Jun 29, 2020 at 3:42 AM Nikolay Suslov <[hidden email]> wrote:
> Thanks Levente,
>
> Yes, seems to be RFB/VNC from the SqueakSource-SqF project page is outdated (at least it is working in Squeak 5.2 and not in 5.3 and later). Your version works fine!
> However, it is interesting what was the reason for that change just in SequenceableCollection #=. As Set, Bitset, SortedCollection etc. classes still use species comparison in #= (checking they have the same set of
> keys)?
>
> Best regards,
> Nikolai
>
> On Mon, Jun 29, 2020 at 3:43 AM Levente Uzonyi <[hidden email]> wrote:
> Hi Nikolai,
>
> On Mon, 29 Jun 2020, Nikolay Suslov wrote:
>
> > Hello all,
> > Figuring out, could we go back to the previous version of SequenceableCollection #= method (as in Squeak 5.2), to check if the receiver is equivalent to the otherCollection by using "self species ==
> otherCollection species",
> > instead of "self class = otherCollection class"?
>
> IIRC there was a good reason for that change though I can't recall
> what it was. I'm sure the mailing list remembers.
>
>
> > The current version of #= method breaks code in different places. For example the RFB/VNC server gives wrong results starting from an authentication process, where RFBMessage is the ByteArray subclass and
> implements #species.
>
> If you're looking for a fix, try this:
> http://leves.web.elte.hu/squeak/RFB-ul.18.mcz
>
>
> Levente
>
> >
> > Best regards,
> > Nikolai
> >
> >
>
>
>
>

Chris Muller-4

Re: SequenceableCollection #= method in current trunk differs from Squeak 5.2

On Tue, Jun 30, 2020 at 7:55 PM Levente Uzonyi <[hidden email]> wrote:

On Tue, 30 Jun 2020, Chris Muller wrote:

> Might be worth reopening this discussion. ANY dependencies on #class seem like a bad thing to me, especially while it's still an in-lined message. Below is the MC version that did it. Looks like the time to change this

Using #class by default sounds correct to me. If some instances of
classes want to be equal to each other, they should handle that
themselves by overriding #=.

Because it causes that same undesirable loss of symmetry you mentioned about MCVersionName and String, except much worse because it's in a more general sense instead of application-specific. It makes headaches for Magma applications because client code has to be aware of it.

Smalltalk wants to be about messages, not types. What do we need to do to make #class non-inlined and therefore overridable? My impression is that this is on the table for 6.0, is it still?

- Chris

Nicolas Cellier

Re: SequenceableCollection #= method in current trunk differs from Squeak 5.2

Le mer. 1 juil. 2020 à 06:01, Chris Muller <[hidden email]> a écrit :

On Tue, Jun 30, 2020 at 7:55 PM Levente Uzonyi <[hidden email]> wrote:
On Tue, 30 Jun 2020, Chris Muller wrote:

> Might be worth reopening this discussion. ANY dependencies on #class seem like a bad thing to me, especially while it's still an in-lined message. Below is the MC version that did it. Looks like the time to change this

Using #class by default sounds correct to me. If some instances of
classes want to be equal to each other, they should handle that
themselves by overriding #=.

Because it causes that same undesirable loss of symmetry you mentioned about MCVersionName and String, except much worse because it's in a more general sense instead of application-specific. It makes headaches for Magma applications because client code has to be aware of it.

Smalltalk wants to be about messages, not types. What do we need to do to make #class non-inlined and therefore overridable? My impression is that this is on the table for 6.0, is it still?

- Chris

Hi Chris,

wait a minute, the failure of symmetry of MCVersionName is ABSOLUTELY UNRELATED to species or class.

There are some wonderful hacks, there are some clever hacks, but at the end, you very well know that you can cheat as long as you don't get caught.

MCVersionName is not a good hack.

Here we are dressing the String with additional application specific semantics.

The MCVersionName is a String which knows how to be interpreted in some context.

There are lot's of contexts where we could dress strings like that, imagine that we create a DateString, a NumberString...

Should we really do that?

When we do that, we confer more responsibilities to such subclasses. They are a String, and also more than a String.

But here, the application specific behavior is in contradiction with superclass, we redefined = with a different behavior.

At the end, we will always get caught with schemes like that, because we complexify and entangle the concepts.

It seems to me that it's a simple inheritance vs composition anti-pattern.

MCVersion name hash ~= MVVersion name asString hash is a good illustration.

It means that we're breaking a more general contract for implementing our hack.

It's typical of what will happen by abuse of inheritance.

Think of it, = is a relationship of equivalence. We don't want to loose that.

So it has to be symmetric, but also transitive:

String new = StringSubclass1 & ( String new = StringSubclass2 new ) ==> (StringSubclass1 new = StringSubclass2 new).

That means that we would have accidental equivalence of separate domains if ever the string representation matches.

That's not what we want.

Also, if StringSubclass1 is more than a String, then how something less than a StringSubclass1 could be equivalent?

It's not equivalent, it does not behave the same, or we would not need to subclass in the first place.

Oh but we have String subclasses, ByteString and WideString, so what's the difference?

The difference is that those are implementation details. They are optimized internal representations of Strings.

We're not at all after conferring a different behavior, on the contrary.

We absolutely want to confer the same behavior to the outside whatever the internal representation (class) and try to make them be really equivalent.

Yes, more than often, the implementation details leak out of encapsulation.

It's the problem of tradeoffs between efficiency and universality. We have to trade some generality for some efficiency.

That's what happens with Interval and Array. They are not equivalent. They have slightly different behaviors and properties.

An Interval is more than an Array (it has numeric elements with arithmetic progression).

And it is less than an Array (it cannot at:put: or embed arbitrary objects).

We can casually have an Array carrying the same elements as an Interval, which can be expressed by #hasEqualElements:

species semantics was overloaded. It did also mean, in which recipient class should I select:, collect:...

If we use the same recipient for collecting, then we are similar (of same species)... And if similar, maybe equal?

It might be that Interval was originally seen as an implementation detail, a (space) optimized version of Array afterall.

But doing so, introduced complexity.

It entangled things.

It broke contracts (hash), or imposed very inefficient implementation of hash (enumerating all elements of an Interval).

In the end, we get caught, that is carrying more inconvenients than advantages when trying to sustain the illusion of equivalence.

It's far better and simpler to just abandon the illusion, because it's just that, a deceitful illusion.

I understand what you mean by abuse of using the class message, we have somehow lost a hook.

But IMO, this hook was not useful, except for one thing proxy.

We have more than one message in our palette, even if = is a very convenient symbol (short binary), we cannot dress it with different context specific meanings, the cheat is getting too apparent.

Levente Uzonyi

Re: SequenceableCollection #= method in current trunk differs from Squeak 5.2

In reply to this post by Chris Muller-4

Hi Chris,

On Tue, 30 Jun 2020, Chris Muller wrote:

> What do we need to do to make #class non-inlined and therefore overridable? My impression is that this is on the table for 6.0, is it still?

We have had this discussion a few times before. Last time[1] I asked you
to evaluate the following in your image and report back if it does what
you need:

(ParseNode classPool at: #StdSelectors) removeKey: #class.
Compiler recompileAll.

Levente

[1] http://forum.world.st/The-Inbox-Kernel-cmm-1198-mcz-td5089411.html#a5089510

>
> - Chris
>
>

Chris Muller-3

Re: SequenceableCollection #= method in current trunk differs from Squeak 5.2

In reply to this post by Nicolas Cellier

Hi Nicolas,

Yes, I understand. For general classes, it's impossible to tolerate non-symmetry. This is an outward-looking tool that didn't need that contract, and took advantage of legacy backward-compatibility via inheritance rather than composition. An encapsulating pointer object would be less efficient (a bunch of extra objects + GC), and face the very same equivalence problem due to Squeak not letting client code define symmetrical equivalence in their subclasses. The fault is not with MCVersionName, it's with our core library.

Q: What does #= have in common with #+, #-, #*, #/ ?

A: It wants to be able to interoperate with different classes for the lvalue and rvalue. That's why the latter four all double-dispatch. The same applies to #=, the only difference is its "calculation" result is a boolean type instead of some Number.

So why can't we double-dispatch with #=, too? Or, maybe we can simply dispatch. To #sameTypeAs:?

Object>>#sameTypeAs: anObject

"Answer whether the receiver is regarded as the same type as anObject."

^ self class = anObject class

(we may need a double-dispatch, but... that's just details)

Interested in your thoughts on the hard type-checking. Observe how String>>#= got a pass that no one else got. Because it was convenient, and because we, the great developers, have full control, we softened it, let it rely on #isString rather than the hardass draconian type-test (via an inlined message even!). But that reveals the limitation, *users* don't have that luxury. They aren't able to make anything similar for any subclass and still maintain symmetric equivalence.

IMO, all this hard type-checking is crippling Squeak's wish to be more dynamic. Magma, too. It could be so great if we would just let it. Would you be open to double-dispatching for #= as with the other binary operators?

Regards,

Chris

On Wed, Jul 1, 2020 at 3:57 AM Nicolas Cellier <[hidden email]> wrote:

Le mer. 1 juil. 2020 à 06:01, Chris Muller <[hidden email]> a écrit :
On Tue, Jun 30, 2020 at 7:55 PM Levente Uzonyi <[hidden email]> wrote:
On Tue, 30 Jun 2020, Chris Muller wrote:

> Might be worth reopening this discussion. ANY dependencies on #class seem like a bad thing to me, especially while it's still an in-lined message. Below is the MC version that did it. Looks like the time to change this

Using #class by default sounds correct to me. If some instances of
classes want to be equal to each other, they should handle that
themselves by overriding #=.

Because it causes that same undesirable loss of symmetry you mentioned about MCVersionName and String, except much worse because it's in a more general sense instead of application-specific. It makes headaches for Magma applications because client code has to be aware of it.

Smalltalk wants to be about messages, not types. What do we need to do to make #class non-inlined and therefore overridable? My impression is that this is on the table for 6.0, is it still?

- Chris

Hi Chris,
wait a minute, the failure of symmetry of MCVersionName is ABSOLUTELY UNRELATED to species or class.

There are some wonderful hacks, there are some clever hacks, but at the end, you very well know that you can cheat as long as you don't get caught.
MCVersionName is not a good hack.

Here we are dressing the String with additional application specific semantics.
The MCVersionName is a String which knows how to be interpreted in some context.
There are lot's of contexts where we could dress strings like that, imagine that we create a DateString, a NumberString...
Should we really do that?
When we do that, we confer more responsibilities to such subclasses. They are a String, and also more than a String.
But here, the application specific behavior is in contradiction with superclass, we redefined = with a different behavior.
At the end, we will always get caught with schemes like that, because we complexify and entangle the concepts.
It seems to me that it's a simple inheritance vs composition anti-pattern.

MCVersion name hash ~= MVVersion name asString hash is a good illustration.
It means that we're breaking a more general contract for implementing our hack.
It's typical of what will happen by abuse of inheritance.

Think of it, = is a relationship of equivalence. We don't want to loose that.
So it has to be symmetric, but also transitive:
String new = StringSubclass1 & ( String new = StringSubclass2 new ) ==> (StringSubclass1 new = StringSubclass2 new).
That means that we would have accidental equivalence of separate domains if ever the string representation matches.
That's not what we want.

Also, if StringSubclass1 is more than a String, then how something less than a StringSubclass1 could be equivalent?
It's not equivalent, it does not behave the same, or we would not need to subclass in the first place.

Oh but we have String subclasses, ByteString and WideString, so what's the difference?
The difference is that those are implementation details. They are optimized internal representations of Strings.
We're not at all after conferring a different behavior, on the contrary.

We absolutely want to confer the same behavior to the outside whatever the internal representation (class) and try to make them be really equivalent.
Yes, more than often, the implementation details leak out of encapsulation.
It's the problem of tradeoffs between efficiency and universality. We have to trade some generality for some efficiency.

That's what happens with Interval and Array. They are not equivalent. They have slightly different behaviors and properties.
An Interval is more than an Array (it has numeric elements with arithmetic progression).
And it is less than an Array (it cannot at:put: or embed arbitrary objects).
We can casually have an Array carrying the same elements as an Interval, which can be expressed by #hasEqualElements:

species semantics was overloaded. It did also mean, in which recipient class should I select:, collect:...
If we use the same recipient for collecting, then we are similar (of same species)... And if similar, maybe equal?

It might be that Interval was originally seen as an implementation detail, a (space) optimized version of Array afterall.

But doing so, introduced complexity.
It entangled things.
It broke contracts (hash), or imposed very inefficient implementation of hash (enumerating all elements of an Interval).
In the end, we get caught, that is carrying more inconvenients than advantages when trying to sustain the illusion of equivalence.

It's far better and simpler to just abandon the illusion, because it's just that, a deceitful illusion.

I understand what you mean by abuse of using the class message, we have somehow lost a hook.
But IMO, this hook was not useful, except for one thing proxy.
We have more than one message in our palette, even if = is a very convenient symbol (short binary), we cannot dress it with different context specific meanings, the cheat is getting too apparent.

Chris Muller-4

Re: SequenceableCollection #= method in current trunk differs from Squeak 5.2

In reply to this post by Levente Uzonyi

Thanks for that reminder, but I was asking about the next Squeak release image. Does anyone object to making this one of the goals for 6.0?

- Chris

On Wed, Jul 1, 2020 at 2:29 PM Levente Uzonyi <[hidden email]> wrote:

Hi Chris,

On Tue, 30 Jun 2020, Chris Muller wrote:

> What do we need to do to make #class non-inlined and therefore overridable? My impression is that this is on the table for 6.0, is it still?

We have had this discussion a few times before. Last time[1] I asked you
to evaluate the following in your image and report back if it does what
you need:

(ParseNode classPool at: #StdSelectors) removeKey: #class.
Compiler recompileAll.

Levente

[1] http://forum.world.st/The-Inbox-Kernel-cmm-1198-mcz-td5089411.html#a5089510

>
> - Chris
>
>

Levente Uzonyi

Re: SequenceableCollection #= method in current trunk differs from Squeak 5.2

On Thu, 2 Jul 2020, Chris Muller wrote:

> Thanks for that reminder, but I was asking about the next Squeak release image. Does anyone object to making this one of the goals for 6.0?

What is "this" you're referring to?

Levente

> - Chris
>
>
> On Wed, Jul 1, 2020 at 2:29 PM Levente Uzonyi <[hidden email]> wrote:
> Hi Chris,
>
> On Tue, 30 Jun 2020, Chris Muller wrote:
>
> > What do we need to do to make #class non-inlined and therefore overridable? My impression is that this is on the table for 6.0, is it still?
>
> We have had this discussion a few times before. Last time[1] I asked you
> to evaluate the following in your image and report back if it does what
> you need:
>
> (ParseNode classPool at: #StdSelectors) removeKey: #class.
> Compiler recompileAll.
>
>
> Levente
>
> [1] http://forum.world.st/The-Inbox-Kernel-cmm-1198-mcz-td5089411.html#a5089510
>
> >
> > - Chris
> >
> >
>
>
>

David T. Lewis

Re: SequenceableCollection #= method in current trunk differs from Squeak 5.2

In reply to this post by Levente Uzonyi

On Mon, Jun 29, 2020 at 02:43:26AM +0200, Levente Uzonyi wrote:

> Hi Nikolai,
>
> On Mon, 29 Jun 2020, Nikolay Suslov wrote:
>
> >Hello all,
> >Figuring out, could we go back to the previous version of
> >SequenceableCollection??#= method (as in Squeak 5.2), to check if the
> >receiver is??equivalent to the otherCollection by using "self species ==
> >otherCollection species",
> >instead of "self class = otherCollection class"?
>
> IIRC there was a good reason for that change though I can't recall
> what it was. I'm sure the mailing list remembers.
>

The change has my initials on it, and it was introduced here:

Name: Collections-dtl.821
Author: dtl
Time: 16 February 2019, 6:18:27.925895 pm
UUID: 9bfa29b3-5e9f-4c61-b19b-e0bb05403589
Ancestors: Collections-nice.820

Classes are expected to be unique in the system, but in some cases (e.g. Magma)
it is also useful to expect a proxy for a class to test equivalent to the
actual class. Therefore, in SequenceableCollection>>= use #= rather than #==
for the class comparison.

The discussion on the list was here:

http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-February/201600.html

Dave

Nicolas Cellier

Re: SequenceableCollection #= method in current trunk differs from Squeak 5.2

Le ven. 3 juil. 2020 à 14:43, David T. Lewis <[hidden email]> a écrit :

On Mon, Jun 29, 2020 at 02:43:26AM +0200, Levente Uzonyi wrote:
> Hi Nikolai,
>
> On Mon, 29 Jun 2020, Nikolay Suslov wrote:
>
> >Hello all,
> >Figuring out, could we go back to the previous version of
> >SequenceableCollection??#= method (as in Squeak 5.2), to check if the
> >receiver is??equivalent to the otherCollection by using "self species ==
> >otherCollection species",
> >instead of "self class = otherCollection class"?
>
> IIRC there was a good reason for that change though I can't recall
> what it was. I'm sure the mailing list remembers.
>

The change has my initials on it, and it was introduced here:

Name: Collections-dtl.821
Author: dtl
Time: 16 February 2019, 6:18:27.925895 pm
UUID: 9bfa29b3-5e9f-4c61-b19b-e0bb05403589
Ancestors: Collections-nice.820

Classes are expected to be unique in the system, but in some cases (e.g. Magma)
it is also useful to expect a proxy for a class to test equivalent to the
actual class. Therefore, in SequenceableCollection>>= use #= rather than #==
for the class comparison.

+1 for using =

The discussion on the list was here:

http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-February/201600.html

Dave

Nikolay Suslov

Re: SequenceableCollection #= method in current trunk differs from Squeak 5.2

In reply to this post by David T. Lewis

Hello David,

On Fri, Jul 3, 2020 at 3:43 PM David T. Lewis <[hidden email]> wrote:

>
> On Mon, Jun 29, 2020 at 02:43:26AM +0200, Levente Uzonyi wrote:
> > Hi Nikolai,
> >
> > On Mon, 29 Jun 2020, Nikolay Suslov wrote:
> >
> > >Hello all,
> > >Figuring out, could we go back to the previous version of
> > >SequenceableCollection??#= method (as in Squeak 5.2), to check if the
> > >receiver is??equivalent to the otherCollection by using "self species ==
> > >otherCollection species",
> > >instead of "self class = otherCollection class"?
> >
> > IIRC there was a good reason for that change though I can't recall
> > what it was. I'm sure the mailing list remembers.
> >
>
> The change has my initials on it, and it was introduced here:
>
> Name: Collections-dtl.821
> Author: dtl
> Time: 16 February 2019, 6:18:27.925895 pm
> UUID: 9bfa29b3-5e9f-4c61-b19b-e0bb05403589
> Ancestors: Collections-nice.820
>
> Classes are expected to be unique in the system, but in some cases (e.g. Magma)
> it is also useful to expect a proxy for a class to test equivalent to the
> actual class. Therefore, in SequenceableCollection>>= use #= rather than #==
> for the class comparison.
>
>
> The discussion on the list was here:
>
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-February/201600.html
>
> Dave
>
>

Thanks for finding that.
But, if you look at the previous version (sma 5/12/2000) of
SequenceableCollection>>=, it checks the equivalents of "species" (the
same 'kind' of thing in collection). So, replacing that with check
equivalents of a "class" introduces a "silent application bug",
especially in code, which expects "species" comparison in
SequenceableCollection>>= (like RFB I mentioned).
Anyway, it is ok to use and upgrade related code to #hasEqualElements:
method instead.
But someone still can find the difference, that in Set, Bitset,
SortedCollection we could use #= for checking equivalents of
"species", but in SequenceableCollection - not, starting from Squeak
5.3

Best regards,
Nikolai

David T. Lewis

Re: SequenceableCollection #= method in current trunk differs from Squeak 5.2

Hello Nikolay,

On Fri, Jul 03, 2020 at 06:43:04PM +0300, Nikolay Suslov wrote:

> Hello David,
>
> On Fri, Jul 3, 2020 at 3:43 PM David T. Lewis <[hidden email]> wrote:
> >
> > On Mon, Jun 29, 2020 at 02:43:26AM +0200, Levente Uzonyi wrote:
> > > Hi Nikolai,
> > >
> > > On Mon, 29 Jun 2020, Nikolay Suslov wrote:
> > >
> > > >Hello all,
> > > >Figuring out, could we go back to the previous version of
> > > >SequenceableCollection??#= method (as in Squeak 5.2), to check if the
> > > >receiver is??equivalent to the otherCollection by using "self species ==
> > > >otherCollection species",
> > > >instead of "self class = otherCollection class"?
> > >
> > > IIRC there was a good reason for that change though I can't recall
> > > what it was. I'm sure the mailing list remembers.
> > >
> >
> > The change has my initials on it, and it was introduced here:
> >
> > Name: Collections-dtl.821
> > Author: dtl
> > Time: 16 February 2019, 6:18:27.925895 pm
> > UUID: 9bfa29b3-5e9f-4c61-b19b-e0bb05403589
> > Ancestors: Collections-nice.820
> >
> > Classes are expected to be unique in the system, but in some cases (e.g. Magma)
> > it is also useful to expect a proxy for a class to test equivalent to the
> > actual class. Therefore, in SequenceableCollection>>= use #= rather than #==
> > for the class comparison.
> >
> >
> > The discussion on the list was here:
> >
> > http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-February/201600.html
> >
> > Dave
> >
> >
>
> Thanks for finding that.
> But, if you look at the previous version (sma 5/12/2000) of
> SequenceableCollection>>=, it checks the equivalents of "species" (the
> same 'kind' of thing in collection). So, replacing that with check
> equivalents of a "class" introduces a "silent application bug",
> especially in code, which expects "species" comparison in
> SequenceableCollection>>= (like RFB I mentioned).
> Anyway, it is ok to use and upgrade related code to #hasEqualElements:
> method instead.
> But someone still can find the difference, that in Set, Bitset,
> SortedCollection we could use #= for checking equivalents of
> "species", but in SequenceableCollection - not, starting from Squeak
> 5.3
>
> Best regards,
> Nikolai

Yes, I can see that your are right. The current version of the
SequenceableCollection>>#= does this:

self class = otherCollection class

and the previous version (sma 5/12/2000) did this:

self species == otherCollection species

I have to say that I am not really qualified to say what is the best
implementation, so I hope that you or others (Nicolas, Levente, Chris?)
can suggest if there is a better way.

For example, is it better to do this (I really do not know):

self species = otherCollection species

Thanks,
Dave

Chris Muller-3

Re: SequenceableCollection #= method in current trunk differs from Squeak 5.2

For example, is it better to do this (I really do not know):

self species = otherCollection species

Nicolas' arguments for Collections-nice.820 are sound, the challenge is that some apps, that don't care about equivalence between Intervals and Array's, were affected in a negative way, and left no good way to fix their code. There's a tendency to want to dismiss them with "use hasEqualElements:" without understanding why hasEqualElements: can't fix the core issue -- the inability to define implementation-specific subclasses with symmetric equivalence (e.g., like ByteString and WideString did for String).

IMO, this is the question we should address. I posed that we should factor out this common type-checking behavior, repeated throughout the class library, into its own method on Object. I think it could work..

- Chris

Trygve

Re: SequenceableCollection #= method in current trunk differs from Squeak 5.2

In reply to this post by Levente Uzonyi

There are two fundamental axioms in Smalltalk:

Everything is an object.
An object is an instance of a class.

The class message is fundamental, If you override it, it is no longer Smalltalk.
Trygve

On 2020-07-01 21:29, Levente Uzonyi wrote:

Hi Chris,

On Tue, 30 Jun 2020, Chris Muller wrote:

What do we need to do to make #class non-inlined and therefore overridable? My impression is that this is on the table for 6.0, is it still?

We have had this discussion a few times before. Last time[1] I asked you to evaluate the following in your image and report back if it does what you need:

(ParseNode classPool at: #StdSelectors) removeKey: #class.
Compiler recompileAll.

Levente

[1] http://forum.world.st/The-Inbox-Kernel-cmm-1198-mcz-td5089411.html#a5089510

- Chris

cbc

Re: SequenceableCollection #= method in current trunk differs from Squeak 5.2

In reply to this post by Levente Uzonyi

On Sun, Jun 28, 2020 at 5:43 PM Levente Uzonyi <[hidden email]> wrote:

Hi Nikolai,

On Mon, 29 Jun 2020, Nikolay Suslov wrote:

> Hello all,
> Figuring out, could we go back to the previous version of SequenceableCollection #= method (as in Squeak 5.2), to check if the receiver is equivalent to the otherCollection by using "self species == otherCollection species",
> instead of "self class = otherCollection class"?

IIRC there was a good reason for that change though I can't recall
what it was. I'm sure the mailing list remembers.

If you search for

#= ==> #hash issues

in the mailing list, I think that thread has the (or a) reason for this change (although the #= change was done by nice, not me).

> The current version of #= method breaks code in different places. For example the RFB/VNC server gives wrong results starting from an authentication process, where RFBMessage is the ByteArray subclass and implements #species.

If you're looking for a fix, try this:
http://leves.web.elte.hu/squeak/RFB-ul.18.mcz

Levente

>
> Best regards,
> Nikolai
>
>