Smalltalk › Cincom › VisualWorks

[VW 7.7] Dictionary>>=, Set>>=

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

29 messages Options

Reinout Heeck-2

Re: [VW 7.7] Dictionary>>=, Set>>=

On 4/6/2011 5:46 PM, Adams, Charles wrote:
> Expectations notwithstanding, this is established behavior. Sometimes
> one has to simply live with the shortcomings of legacy code. Dictionary
> is one of those classes that needs to remain inviolate.
I disagree, IMO the core classes should become 'cleaner' over time.

So I am very happy that simple minded code like
#('foo' 'bar') asSet = #( 'bar' 'foo') asSet
finally works as expected (after 30 years :-).

Dictionary>>select: has changed behavior recently, in practice I found
this change did not induce a high porting cost.
It seems the mistake was that the change of #= (and how to chase down
its usage) was not documented in the release notes.

Anyway, using legacy code on a newer toolchain _always_ involves a
porting/validation effort.
Dependency hell cannot be 'wished away'...

R
-

>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
> Behalf Of Terry Raymond
> Sent: Wednesday, April 06, 2011 10:17 AM
> To: 'vwnc NC'
> Subject: Re: [vwnc] [VW 7.7] Dictionary>>=, Set>>=
>
> Charles
>
> I would have to disagree with you on that point.
> The old behavior was "unexpected" most smalltalkers would expect all
> collections to return true for "CollX new = CollX new".
> #= means equivalent, or can A substitute for B.
>
> I think changing it is the right thing to do. However, Cincom should put
> a prominent notice in the release notes whenever any historical base
> behavior is changed.
>
> Terry
>
> ===========================================================
> Terry Raymond
> Crafted Smalltalk
> 80 Lazywood Ln.
> Tiverton, RI 02878
> (401) 624-4517 [hidden email]
> <http://www.craftedsmalltalk.com>
> ===========================================================
>> -----Original Message-----
>> From: [hidden email] [mailto:[hidden email]] On
>> Behalf Of Adams, Charles
>> Sent: Wednesday, April 06, 2011 10:37 AM
>> To: Boris Popov, DeepCove Labs; Niall Ross
>> Cc: vwnc NC
>> Subject: Re: [vwnc] [VW 7.7] Dictionary>>=, Set>>=
>>
>> Boris, that's just hyperbole. This misstep is unrelated to new
>> development.
>>
>> Dictionary is a base Smalltalk class. It's history goes back decades.
>> Changing a base class' basic behavior is, IMHO, unreasonable. Add all
>> the new functionality you want, just don't mess with base classes. If
>> you don't like Dictionary>>=, extend Dictionary with
>> Dictionary>>noReallyEquals, or whatever. I did.
>>
>>
>>
>> -----Original Message-----
>> From: Boris Popov, DeepCove Labs [mailto:[hidden email]]
>> Sent: Wednesday, April 06, 2011 9:27 AM
>> To: Adams, Charles; Niall Ross
>> Cc: vwnc NC
>> Subject: RE: [vwnc] [VW 7.7] Dictionary>>=, Set>>=
>>
>> Ah, but now that it's been in the release for a while, how do you go
>> about not affecting code that now depends on new functionality? If we
>> all decide to never change anything, we may as well ask Cincom to
>> suspend development of new versions...
>>
>> -Boris
>>
>> -----Original Message-----
>> From: [hidden email] [mailto:[hidden email]] On
>> Behalf Of Adams, Charles
>> Sent: 06 April 2011 10:21
>> To: Niall Ross
>> Cc: vwnc NC
>> Subject: Re: [vwnc] [VW 7.7] Dictionary>>=, Set>>=
>>
>> Since this change was made at customer request, I officially request,
>> as a customer, that it be reverted.
>>
>>
>> -----Original Message-----
>> From: Niall Ross [mailto:[hidden email]]
>> Sent: Tuesday, April 05, 2011 2:32 PM
>> To: Adams, Charles
>> Cc: Randy Coulman; vwnc NC
>> Subject: Re: [vwnc] [VW 7.7] Dictionary>>=, Set>>=
>>
>> Dear Charles,
>>
>>> I know for a fact it was in the list of Fixed ARs for that release,
>>> because I made myself a note to determine if this was an issue for
>>> us or not. I realize that the Fixed AR list is not the release
>>> notes, but
>>> I definitely remember this change coming through where I saw it.
>>>
>>> Randy
>>>
>> Yes
>> 46458 [Enh] Why not implement #= and #hash for Sets?
>> and related
>> 54829 Typo in Dictionary>>= comment
>> but in fact I'd agree that it also deserved a release notes para,
>> since it does have potential to impact things unobviously.
>>
>>> [hidden email]> wrote:
>>>
>>>
>>>> I found no mention of Dictionary in the 7.7 or 7.7.1 release notes.
>>>> I don't have the patience to search for "set".
>>>>
>>>>
>> I sympathise (I believe the entry for 'set' is the longest in the
>> Oxford English Dictionary). I confirm there is no Set>>= explanation
> there.
>> I'm guessing you feel you have an answer to the unfortunately-phrased
>> "Why not..." of the AR title - but in fact it was at customer request
>> that this change was made.
>>
>>>> I understand the surprise at the old behavior. That doesn't mean
>>>> it's ok to perturb production software.
>>>>
>>>>
>> Speaking theoretically, code that relies on identity should be using
>> ==, or an IdentitySet or similar for a collection where includes: is
>> relying on identity. Speaking practically, it's understandable that
>> since == is the default for =, this distinction is not always observed
> in old code.
>> Some thoughts in my email to Sonia on how to detect.
>>
>> Yours faithfully
>> Niall Ross
>>
>>
>> _______________________________________________
>> vwnc mailing list
>> [hidden email]
>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>>
>> _______________________________________________
>> vwnc mailing list
>> [hidden email]
>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>

--
*********************************************************************

Dit e-mailbericht is alleen bestemd voor de geadresseerde(n).

Gebruik door anderen is niet toegestaan. Indien u niet degeadresseerde(n) bent wordt u verzocht de verzender hiervan op de hoogte te stellen en het bericht te verwijderen. Door de elektronische verzending kunnen aan de inhoud van dit bericht geen rechten worden ontleend.

Soops B.V. is gevestigd te Amsterdam, Nederland, en is geregistreerd bij de Kamer van Koophandel onder nummer 33240368.
Soops B.V. levert volgens de Fenit voorwaarden, gedeponeerd te Den Haag op 8 december 1994 onder nummer 1994/189.
**********************************************************************

This e-mail message is intended to be exclusively for the addressee.

If you are not the intended recipient you are kindly requested not to make any use whatsoever of the contents and to notify the sender immediately by returning this e-mail message. No rights can be derived from this message.

Soops B.V. is a private limited liability company and has its seat at Amsterdam, The Netherlands and is registered with the Trade Registry of the Chamber of Commerce and Industry under number 33240368.
Soops B.V. delivers according to the General Terms and Conditions of Business of Fenit, registered at The Hague, The Netherlands on December 8th, 1994, under number 1994/189
**********************************************************************

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Adams, Charles

Re: [VW 7.7] Dictionary>>=, Set>>=

...and no one is stopping you from creating your own class.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On
Behalf Of Reinout Heeck
Sent: Wednesday, April 06, 2011 12:54 PM
To: [hidden email]
Subject: Re: [vwnc] [VW 7.7] Dictionary>>=, Set>>=

On 4/6/2011 5:46 PM, Adams, Charles wrote:
> Expectations notwithstanding, this is established behavior. Sometimes
> one has to simply live with the shortcomings of legacy code.
> Dictionary is one of those classes that needs to remain inviolate.
I disagree, IMO the core classes should become 'cleaner' over time.

So I am very happy that simple minded code like
#('foo' 'bar') asSet = #( 'bar' 'foo') asSet finally works as
expected (after 30 years :-).

Dictionary>>select: has changed behavior recently, in practice I found
this change did not induce a high porting cost.
It seems the mistake was that the change of #= (and how to chase down
its usage) was not documented in the release notes.

Anyway, using legacy code on a newer toolchain _always_ involves a
porting/validation effort.
Dependency hell cannot be 'wished away'...

R
-

put

> a prominent notice in the release notes whenever any historical base
> behavior is changed.
>
> Terry
>
> ===========================================================
> Terry Raymond
> Crafted Smalltalk
> 80 Lazywood Ln.
> Tiverton, RI 02878
> (401) 624-4517 [hidden email]
> <http://www.craftedsmalltalk.com>
> ===========================================================
>> -----Original Message-----
>> From: [hidden email] [mailto:[hidden email]] On
>> Behalf Of Adams, Charles
>> Sent: Wednesday, April 06, 2011 10:37 AM
>> To: Boris Popov, DeepCove Labs; Niall Ross
>> Cc: vwnc NC
>> Subject: Re: [vwnc] [VW 7.7] Dictionary>>=, Set>>=
>>
>> Boris, that's just hyperbole. This misstep is unrelated to new
>> development.
>>
>> Dictionary is a base Smalltalk class. It's history goes back decades.
>> Changing a base class' basic behavior is, IMHO, unreasonable. Add all
>> the new functionality you want, just don't mess with base classes. If
>> you don't like Dictionary>>=, extend Dictionary with
>> Dictionary>>noReallyEquals, or whatever. I did.
>>
>>
>>
>> -----Original Message-----
>> From: Boris Popov, DeepCove Labs [mailto:[hidden email]]
>> Sent: Wednesday, April 06, 2011 9:27 AM
>> To: Adams, Charles; Niall Ross
>> Cc: vwnc NC
>> Subject: RE: [vwnc] [VW 7.7] Dictionary>>=, Set>>=
>>
>> Ah, but now that it's been in the release for a while, how do you go
>> about not affecting code that now depends on new functionality? If we
>> all decide to never change anything, we may as well ask Cincom to
>> suspend development of new versions...
>>
>> -Boris
>>
>> -----Original Message-----
>> From: [hidden email] [mailto:[hidden email]] On
>> Behalf Of Adams, Charles
>> Sent: 06 April 2011 10:21
>> To: Niall Ross
>> Cc: vwnc NC
>> Subject: Re: [vwnc] [VW 7.7] Dictionary>>=, Set>>=
>>
>> Since this change was made at customer request, I officially request,
>> as a customer, that it be reverted.
>>
>>
>> -----Original Message-----
>> From: Niall Ross [mailto:[hidden email]]
>> Sent: Tuesday, April 05, 2011 2:32 PM
>> To: Adams, Charles
>> Cc: Randy Coulman; vwnc NC
>> Subject: Re: [vwnc] [VW 7.7] Dictionary>>=, Set>>=
>>
>> Dear Charles,
>>
>>> I know for a fact it was in the list of Fixed ARs for that release,
>>> because I made myself a note to determine if this was an issue for
>>> us or not. I realize that the Fixed AR list is not the release
>>> notes, but
>>> I definitely remember this change coming through where I saw it.
>>>
>>> Randy
>>>
>> Yes
>> 46458 [Enh] Why not implement #= and #hash for Sets?
>> and related
>> 54829 Typo in Dictionary>>= comment
>> but in fact I'd agree that it also deserved a release notes para,
>> since it does have potential to impact things unobviously.
>>
>>> [hidden email]> wrote:
>>>
>>>
>>>> I found no mention of Dictionary in the 7.7 or 7.7.1 release notes.
>>>> I don't have the patience to search for "set".
>>>>
>>>>
>> I sympathise (I believe the entry for 'set' is the longest in the
>> Oxford English Dictionary). I confirm there is no Set>>= explanation
> there.
>> I'm guessing you feel you have an answer to the unfortunately-phrased
>> "Why not..." of the AR title - but in fact it was at customer request
>> that this change was made.
>>
>>>> I understand the surprise at the old behavior. That doesn't mean
>>>> it's ok to perturb production software.
>>>>
>>>>
>> Speaking theoretically, code that relies on identity should be using
>> ==, or an IdentitySet or similar for a collection where includes: is
>> relying on identity. Speaking practically, it's understandable that
>> since == is the default for =, this distinction is not always

observed

> in old code.
>> Some thoughts in my email to Sonia on how to detect.
>>
>> Yours faithfully
>> Niall Ross
>>
>>
>> _______________________________________________
>> vwnc mailing list
>> [hidden email]
>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>>
>> _______________________________________________
>> vwnc mailing list
>> [hidden email]
>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>

--
*********************************************************************

Dit e-mailbericht is alleen bestemd voor de geadresseerde(n).

Gebruik door anderen is niet toegestaan. Indien u niet
degeadresseerde(n) bent wordt u verzocht de verzender hiervan op de
hoogte te stellen en het bericht te verwijderen. Door de elektronische
verzending kunnen aan de inhoud van dit bericht geen rechten worden
ontleend.

Soops B.V. is gevestigd te Amsterdam, Nederland, en is geregistreerd bij
de Kamer van Koophandel onder nummer 33240368.
Soops B.V. levert volgens de Fenit voorwaarden, gedeponeerd te Den Haag
op 8 december 1994 onder nummer 1994/189.
**********************************************************************

This e-mail message is intended to be exclusively for the addressee.

If you are not the intended recipient you are kindly requested not to
make any use whatsoever of the contents and to notify the sender
immediately by returning this e-mail message. No rights can be derived
from this message.

Soops B.V. is a private limited liability company and has its seat at
Amsterdam, The Netherlands and is registered with the Trade Registry of
the Chamber of Commerce and Industry under number 33240368.
Soops B.V. delivers according to the General Terms and Conditions of
Business of Fenit, registered at The Hague, The Netherlands on December
8th, 1994, under number 1994/189
**********************************************************************

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

andre

Re: [VW 7.7] Dictionary>>=, Set>>=

In reply to this post by Cooper, Becky

I for one appreciate the fix of a 30 year old oddity that was
absolutely ill and inconsistent. I just tried

#('Hello' 'Me') asSet = #('Me' 'Hello') asSet -> false

and was shocked and surprised. By pure accident, I didn't notice this
in over 20 years. During the past years this might have broken subtle
things in the underpinnings of my pattern recognition. Heursitic AI is
hard to verify and prove correct, so one has to rely on quantitative
measures and plausibility. Results are seldom right or wrong, but
rather something in between, as close to "right" as posible, of
course. Therefore I am curious whether the equality fix will have any
positive effect on my algorithms.

Fixing things in base classes does not necessarily break existing
code. It can also /fix/ existing code where issues were just not yet
clearly identified.

I vaguely remember a problem with LargeInteger that broke the window
handle registry.

IMHO, if a "do not touch anything" production software is to be kept
safe, the simplest option is to stay with a certain VW release and
backport selected fixes only. Once every five years or so, one may
feel it is time to make the move to the latest VM and allocate
sufficient resources for that.

Current development should always look into the future, be pure and
radical in a way, searching for the best possible solution. Migration
issues should be second concern, albeit properly documented, as
Smalltalk is greatly prepared for that sort of change anyway (better
than any other language).

Where fear governs development, a product will slowly fade away.

Andre

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Alan Knight-2

Re: [VW 7.7] Dictionary>>=, Set>>=

In reply to this post by Cooper, Becky

I agree that we should have had that as a release note, and it would be good to provide assistance for people who might be affected by such problems. Obviously we can't possibly test all implications for customer implications, but providing migration assistance would be helpful. I do note that, for Sets, this appears to be a change that every other living Smalltalk dialect has also made, and for Dictionaries, all but VA. I think VA may be the only one in which Dictionary does not inherit from Set.

In terms of finding changes, I think probably the most useful thing would be to instrument the equality method for the classes in question and if two are returning equal but are not identical, dump out the context, and look at those contexts for any implications for the application. Then have the instrumentation in while doing testing of the application. There are a number of ways of doing that sort of instrumentation. A particularly convenient one that was mentioned the other day is to load the Out package from the public repository, which defines methods out: and stdout: on contexts. So, e.g.
thisContext stdout: 30
would dump the first 30 method names to standard out (on Windows, you'd need to be running with the vwntconsole.exe VM in order to have stdout go anywhere useful, and you'd probably want to redirect it to a file on any platform).

[hidden email]
April 6, 2011 1:33 PM

How is overriding the new behavior and hoping it doesn't cause problems
in the base image an acceptable solution?  We can't possibly test all of
VW to the extent Cincom can/should.  Even Cincom has not uncovered all
their own porting issues caused by this change.  We just found one.  How
many more might there be?  The subtle differences in behavior are
dangerous and will be hard to isolate.

A prominent notice should be given, agreed.  But Boris' note about a
migration path forward is even more important.  This isn't a change that
always produces "in-your-face" errors.  More consideration should have
been given to how long-time customers who make heavy use of Dictionaries
and Sets will deal with this kind of change; less should have been given
to newer VW users who were merely "surprised" by the established
behavior.

Becky
   

-----Original Message-----
From: [hidden email] [[hidden email]] On
Behalf Of Steven Kelly
Sent: Wednesday, April 06, 2011 10:39 AM
To: vwnc NC
Subject: Re: [vwnc] [VW 7.7] Dictionary>>=, Set>>=

OK, so the base was semantically wrong, and has now been corrected.
Every new version brings up problems like this, breaking existing code.
Maybe this broke more code for some customers than other versions, maybe
even more code over all customers (which I doubt). 

For those whose code did break, of course you have my sympathy. If you
really don't like it, the simplest thing may just be to override it back
to the old behavior. Some bits of the base image may stop working, but I
doubt there is a major problem. I just tried it, and no problem so far.

Let's send bug reports for things that are wrong, not for things that
were wrong and have been made right (in this case, back in 2009). Or
does anyone seriously claim that semantically an empty set is not equal
to another empty set?

In 7.7, there are only 8 Collection subclasses for which an empty
instance is not equal to another empty instance. 56 subclasses say they
are equal, and those are the central classes - 300,000 instances
compared to just 4,000 for the non-equality classes. I think the
non-equality classes should also be reconsidered, and perhaps answer
true too:

  instCount      class          (self new: 0) = (self new: 0)
1:  4010 -> MethodDictionary -> false
2:  25   -> ColorPreferencesDictionary -> false
3:  17   -> ExternalDictionary -> false
4:  4    -> StopsDictionary -> false
5:  1    -> PDPWeakCollection -> false
6:  1    -> PDPWeakDictionary -> false
7:  0    -> LinkedWeakAssociationDictionary -> false
8:  0    -> OrderedSet -> false

In addition, there is a bug in 7.6 and 7.7's Symbol (and concrete
subclasses), which allows "Symbol new: 0" and says it is not = to
another "Symbol new: 0". That's in contravention of Symbol's comment,
which says that if two Strings are =, then their Symbols are ==.

Steve

-----Original Message-----
From: [hidden email] [[hidden email]] On
Behalf Of Adams, Charles
Sent: 6. huhtikuuta 2011 17:37
To: Boris Popov, DeepCove Labs; Niall Ross
Cc: vwnc NC
Subject: Re: [vwnc] [VW 7.7] Dictionary>>=, Set>>=

Boris, that's just hyperbole. This misstep is unrelated to new
development.

Dictionary is a base Smalltalk class. It's history goes back decades.
Changing a base class' basic behavior is, IMHO, unreasonable. Add all
the new functionality you want, just don't mess with base classes. If
you don't like Dictionary>>=, extend Dictionary with
Dictionary>>noReallyEquals, or whatever. I did.

-----Original Message-----
From: Boris Popov, DeepCove Labs [[hidden email]]
Sent: Wednesday, April 06, 2011 9:27 AM
To: Adams, Charles; Niall Ross
Cc: vwnc NC
Subject: RE: [vwnc] [VW 7.7] Dictionary>>=, Set>>=

Ah, but now that it's been in the release for a while, how do you go
about not affecting code that now depends on new functionality? If we
all decide to never change anything, we may as well ask Cincom to
suspend development of new versions...

-Boris

-----Original Message-----
From: [hidden email] [[hidden email]] On
Behalf Of Adams, Charles
Sent: 06 April 2011 10:21
To: Niall Ross
Cc: vwnc NC
Subject: Re: [vwnc] [VW 7.7] Dictionary>>=, Set>>=

Since this change was made at customer request, I officially request,
as
a customer, that it be reverted.

-----Original Message-----
From: Niall Ross [[hidden email]]
Sent: Tuesday, April 05, 2011 2:32 PM
To: Adams, Charles
Cc: Randy Coulman; vwnc NC
Subject: Re: [vwnc] [VW 7.7] Dictionary>>=, Set>>=

Dear Charles,

I know for a fact it was in the list of Fixed ARs for that release,
because I made myself a note  to determine if this was an issue for

us

or not.  I realize that the Fixed AR list is not the release notes,

but

I definitely remember this change coming through where I saw it.

Randy

Yes
    46458    [Enh] Why not implement #= and #hash for Sets?
and related
    54829    Typo in Dictionary>>= comment
but in fact I'd agree that it also deserved a release notes para,

since

it does have potential to impact things unobviously.

[hidden email]> wrote:

I found no mention of Dictionary in the 7.7 or 7.7.1 release notes.

don't have the patience to search for "set".

I sympathise (I believe the entry for 'set' is the longest in the
Oxford
English Dictionary).  I confirm there is no Set>>= explanation there.

I'm guessing you feel you have an answer to the unfortunately-phrased
"Why not..." of the AR title - but in fact it was at customer request
that this change was made.

I understand the surprise at the old behavior. That doesn't mean

it's

ok to perturb production software.

Speaking theoretically, code that relies on identity should be using

==,

or an IdentitySet or similar for a collection where includes: is
relying
on identity.  Speaking practically, it's understandable that since ==
is
the default for =, this distinction is not always observed in old

code.

Some thoughts in my email to Sonia on how to detect.

             Yours faithfully
                   Niall Ross


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

[hidden email]
April 6, 2011 11:38 AM

OK, so the base was semantically wrong, and has now been corrected.
Every new version brings up problems like this, breaking existing code.
Maybe this broke more code for some customers than other versions, maybe
even more code over all customers (which I doubt). 

For those whose code did break, of course you have my sympathy. If you
really don't like it, the simplest thing may just be to override it back
to the old behavior. Some bits of the base image may stop working, but I
doubt there is a major problem. I just tried it, and no problem so far.

Let's send bug reports for things that are wrong, not for things that
were wrong and have been made right (in this case, back in 2009). Or
does anyone seriously claim that semantically an empty set is not equal
to another empty set?

In 7.7, there are only 8 Collection subclasses for which an empty
instance is not equal to another empty instance. 56 subclasses say they
are equal, and those are the central classes - 300,000 instances
compared to just 4,000 for the non-equality classes. I think the
non-equality classes should also be reconsidered, and perhaps answer
true too:

  instCount      class          (self new: 0) = (self new: 0)
1:  4010 -> MethodDictionary -> false
2:  25   -> ColorPreferencesDictionary -> false
3:  17   -> ExternalDictionary -> false
4:  4    -> StopsDictionary -> false
5:  1    -> PDPWeakCollection -> false
6:  1    -> PDPWeakDictionary -> false
7:  0    -> LinkedWeakAssociationDictionary -> false
8:  0    -> OrderedSet -> false

In addition, there is a bug in 7.6 and 7.7's Symbol (and concrete
subclasses), which allows "Symbol new: 0" and says it is not = to
another "Symbol new: 0". That's in contravention of Symbol's comment,
which says that if two Strings are =, then their Symbols are ==.

Steve

-----Original Message-----
From: [hidden email] [[hidden email]] On
Behalf Of Adams, Charles
Sent: 6. huhtikuuta 2011 17:37
To: Boris Popov, DeepCove Labs; Niall Ross
Cc: vwnc NC
Subject: Re: [vwnc] [VW 7.7] Dictionary>>=, Set>>=

Boris, that's just hyperbole. This misstep is unrelated to new
development.

Dictionary is a base Smalltalk class. It's history goes back decades.
Changing a base class' basic behavior is, IMHO, unreasonable. Add all
the new functionality you want, just don't mess with base classes. If
you don't like Dictionary>>=, extend Dictionary with
Dictionary>>noReallyEquals, or whatever. I did.

-----Original Message-----
From: Boris Popov, DeepCove Labs [[hidden email]]
Sent: Wednesday, April 06, 2011 9:27 AM
To: Adams, Charles; Niall Ross
Cc: vwnc NC
Subject: RE: [vwnc] [VW 7.7] Dictionary>>=, Set>>=

Ah, but now that it's been in the release for a while, how do you go
about not affecting code that now depends on new functionality? If we
all decide to never change anything, we may as well ask Cincom to
suspend development of new versions...

-Boris

-----Original Message-----
From: [hidden email] [[hidden email]] On
Behalf Of Adams, Charles
Sent: 06 April 2011 10:21
To: Niall Ross
Cc: vwnc NC
Subject: Re: [vwnc] [VW 7.7] Dictionary>>=, Set>>=

Since this change was made at customer request, I officially request,
as
a customer, that it be reverted.

-----Original Message-----
From: Niall Ross [[hidden email]]
Sent: Tuesday, April 05, 2011 2:32 PM
To: Adams, Charles
Cc: Randy Coulman; vwnc NC
Subject: Re: [vwnc] [VW 7.7] Dictionary>>=, Set>>=

Dear Charles,

I know for a fact it was in the list of Fixed ARs for that release,
because I made myself a note  to determine if this was an issue for

us

or not.  I realize that the Fixed AR list is not the release notes,

but

I definitely remember this change coming through where I saw it.

Randy

Yes
    46458    [Enh] Why not implement #= and #hash for Sets?
and related
    54829    Typo in Dictionary>>= comment
but in fact I'd agree that it also deserved a release notes para,

since

it does have potential to impact things unobviously.

[hidden email]> wrote:

I found no mention of Dictionary in the 7.7 or 7.7.1 release notes.

don't have the patience to search for "set".

I sympathise (I believe the entry for 'set' is the longest in the
Oxford
English Dictionary).  I confirm there is no Set>>= explanation there.

I'm guessing you feel you have an answer to the unfortunately-phrased
"Why not..." of the AR title - but in fact it was at customer request
that this change was made.

I understand the surprise at the old behavior. That doesn't mean

it's

ok to perturb production software.

Speaking theoretically, code that relies on identity should be using

==,

or an IdentitySet or similar for a collection where includes: is
relying
on identity.  Speaking practically, it's understandable that since ==
is
the default for =, this distinction is not always observed in old

code.

Some thoughts in my email to Sonia on how to detect.

             Yours faithfully
                   Niall Ross


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

[hidden email]
April 6, 2011 10:37 AM

Boris, that's just hyperbole. This misstep is unrelated to new
development. 

Dictionary is a base Smalltalk class. It's history goes back decades.
Changing a base class' basic behavior is, IMHO, unreasonable. Add all
the new functionality you want, just don't mess with base classes. If
you don't like Dictionary>>=, extend Dictionary with
Dictionary>>noReallyEquals, or whatever. I did.



-----Original Message-----
From: Boris Popov, DeepCove Labs [[hidden email]] 
Sent: Wednesday, April 06, 2011 9:27 AM
To: Adams, Charles; Niall Ross
Cc: vwnc NC
Subject: RE: [vwnc] [VW 7.7] Dictionary>>=, Set>>=

Ah, but now that it's been in the release for a while, how do you go
about not affecting code that now depends on new functionality? If we
all decide to never change anything, we may as well ask Cincom to
suspend development of new versions...

-Boris

-----Original Message-----
From: [hidden email] [[hidden email]] On
Behalf Of Adams, Charles
Sent: 06 April 2011 10:21
To: Niall Ross
Cc: vwnc NC
Subject: Re: [vwnc] [VW 7.7] Dictionary>>=, Set>>=

Since this change was made at customer request, I officially request, as
a customer, that it be reverted.


-----Original Message-----
From: Niall Ross [[hidden email]]
Sent: Tuesday, April 05, 2011 2:32 PM
To: Adams, Charles
Cc: Randy Coulman; vwnc NC
Subject: Re: [vwnc] [VW 7.7] Dictionary>>=, Set>>=

Dear Charles,

I know for a fact it was in the list of Fixed ARs for that release, 
because I made myself a note  to determine if this was an issue for us 
or not.  I realize that the Fixed AR list is not the release notes, but

I definitely remember this change coming through where I saw it.

Randy

Yes
    46458    [Enh] Why not implement #= and #hash for Sets?
and related
    54829    Typo in Dictionary>>= comment
but in fact I'd agree that it also deserved a release notes para, since
it does have potential to impact things unobviously.

[hidden email]> wrote:

I found no mention of Dictionary in the 7.7 or 7.7.1 release notes. I 
don't have the patience to search for "set".

I sympathise (I believe the entry for 'set' is the longest in the Oxford
English Dictionary).  I confirm there is no Set>>= explanation there.

I'm guessing you feel you have an answer to the unfortunately-phrased
"Why not..." of the AR title - but in fact it was at customer request
that this change was made.

I understand the surprise at the old behavior. That doesn't mean it's 
ok to perturb production software.

Speaking theoretically, code that relies on identity should be using ==,
or an IdentitySet or similar for a collection where includes: is relying
on identity.  Speaking practically, it's understandable that since == is
the default for =, this distinction is not always observed in old code.

Some thoughts in my email to Sonia on how to detect.

             Yours faithfully
                   Niall Ross


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

[hidden email]
April 6, 2011 10:26 AM

Ah, but now that it's been in the release for a while, how do you go
about not affecting code that now depends on new functionality? If we
all decide to never change anything, we may as well ask Cincom to
suspend development of new versions...

-Boris

-----Original Message-----
From: [hidden email] [[hidden email]] On
Behalf Of Adams, Charles
Sent: 06 April 2011 10:21
To: Niall Ross
Cc: vwnc NC
Subject: Re: [vwnc] [VW 7.7] Dictionary>>=, Set>>=

Since this change was made at customer request, I officially request, as
a customer, that it be reverted.


-----Original Message-----
From: Niall Ross [[hidden email]]
Sent: Tuesday, April 05, 2011 2:32 PM
To: Adams, Charles
Cc: Randy Coulman; vwnc NC
Subject: Re: [vwnc] [VW 7.7] Dictionary>>=, Set>>=

Dear Charles,

I know for a fact it was in the list of Fixed ARs for that release, 
because I made myself a note  to determine if this was an issue for us 
or not.  I realize that the Fixed AR list is not the release notes, but

I definitely remember this change coming through where I saw it.

Randy

Yes
    46458    [Enh] Why not implement #= and #hash for Sets?
and related
    54829    Typo in Dictionary>>= comment
but in fact I'd agree that it also deserved a release notes para, since
it does have potential to impact things unobviously.

[hidden email]> wrote:

I found no mention of Dictionary in the 7.7 or 7.7.1 release notes. I 
don't have the patience to search for "set".

I sympathise (I believe the entry for 'set' is the longest in the Oxford
English Dictionary).  I confirm there is no Set>>= explanation there.

I'm guessing you feel you have an answer to the unfortunately-phrased
"Why not..." of the AR title - but in fact it was at customer request
that this change was made.

I understand the surprise at the old behavior. That doesn't mean it's 
ok to perturb production software.

Speaking theoretically, code that relies on identity should be using ==,
or an IdentitySet or similar for a collection where includes: is relying
on identity.  Speaking practically, it's understandable that since == is
the default for =, this distinction is not always observed in old code.

Some thoughts in my email to Sonia on how to detect.

             Yours faithfully
                   Niall Ross


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

[hidden email]
April 6, 2011 10:21 AM

Since this change was made at customer request, I officially request, as
a customer, that it be reverted.

-----Original Message-----
From: Niall Ross [[hidden email]] 
Sent: Tuesday, April 05, 2011 2:32 PM
To: Adams, Charles
Cc: Randy Coulman; vwnc NC
Subject: Re: [vwnc] [VW 7.7] Dictionary>>=, Set>>=

Dear Charles,

I know for a fact it was in the list of Fixed ARs for that release, 
because I made myself a note  to determine if this was an issue for us 
or not.  I realize that the Fixed AR list is not the release notes, but

I definitely remember this change coming through where I saw it.

Randy

Yes
    46458    [Enh] Why not implement #= and #hash for Sets?
and related
    54829    Typo in Dictionary>>= comment
but in fact I'd agree that it also deserved a release notes para, since
it does have potential to impact things unobviously.

[hidden email]> wrote:

I found no mention of Dictionary in the 7.7 or 7.7.1 release notes. I 
don't have the patience to search for "set".

I sympathise (I believe the entry for 'set' is the longest in the Oxford
English Dictionary).  I confirm there is no Set>>= explanation there.

I'm guessing you feel you have an answer to the unfortunately-phrased
"Why not..." of the AR title - but in fact it was at customer request
that this change was made.

I understand the surprise at the old behavior. That doesn't mean it's 
ok to perturb production software.

Speaking theoretically, code that relies on identity should be using ==,
or an IdentitySet or similar for a collection where includes: is relying
on identity.  Speaking practically, it's understandable that since == is
the default for =, this distinction is not always observed in old code.

Some thoughts in my email to Sonia on how to detect.

             Yours faithfully
                   Niall Ross


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

--
Alan Knight [|], Engineering Manager, Cincom Smalltalk
[hidden email]
[hidden email]
http://www.cincomsmalltalk.com

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Travis Griggs-4

Re: [VW 7.7] Dictionary>>=, Set>>=

On Apr 7, 2011, at 9:16 AM, Alan Knight wrote:

> In terms of finding changes, I think probably the most useful thing would be to instrument the equality method for the classes in question and if two are returning equal but are not identical, dump out the context, and look at those contexts for any implications for the application. Then have the instrumentation in while doing testing of the application. There are a number of ways of doing that sort of instrumentation. A particularly convenient one that was mentioned the other day is to load the Out package from the public repository, which defines methods out: and stdout: on contexts. So, e.g.
> thisContext stdout: 30
> would dump the first 30 method names to standard out (on Windows, you'd need to be running with the vwntconsole.exe VM in order to have stdout go anywhere useful, and you'd probably want to redirect it to a file on any platform).

Well, in a couple minutes at least. I haven't replicated that up to the OR in a bit, the stdout: was a bit later.

--
Travis Griggs
Objologist
"The best way to know you have a mind is to change it" -Judge Pierre Leval

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Cooper, Becky

Re: [VW 7.7] Dictionary>>=, Set>>=

In reply to this post by Alan Knight-2

Alan,

Thank you for the advice!

Becky

From: Alan Knight [mailto:[hidden email]]
Sent: Thursday, April 07, 2011 11:16 AM
To: Cooper, Becky
Cc: Steven Kelly; vwnc NC
Subject: Re: [vwnc] [VW 7.7] Dictionary>>=, Set>>=

[hidden email]
April 6, 2011 1:33 PM

How is overriding the new behavior and hoping it doesn't cause problems

in the base image an acceptable solution?  We can't possibly test all of

VW to the extent Cincom can/should.  Even Cincom has not uncovered all

their own porting issues caused by this change.  We just found one.  How

many more might there be?  The subtle differences in behavior are

dangerous and will be hard to isolate.

A prominent notice should be given, agreed.  But Boris' note about a

migration path forward is even more important.  This isn't a change that

always produces "in-your-face" errors.  More consideration should have

been given to how long-time customers who make heavy use of Dictionaries

and Sets will deal with this kind of change; less should have been given

to newer VW users who were merely "surprised" by the established

behavior.

Becky

-----Original Message-----

From: [hidden email] [[hidden email]] On

Behalf Of Steven Kelly

Sent: Wednesday, April 06, 2011 10:39 AM

To: vwnc NC

Subject: Re: [vwnc] [VW 7.7] Dictionary>>=, Set>>=

OK, so the base was semantically wrong, and has now been corrected.

Every new version brings up problems like this, breaking existing code.

Maybe this broke more code for some customers than other versions, maybe

even more code over all customers (which I doubt).

For those whose code did break, of course you have my sympathy. If you

really don't like it, the simplest thing may just be to override it back

to the old behavior. Some bits of the base image may stop working, but I

doubt there is a major problem. I just tried it, and no problem so far.

Let's send bug reports for things that are wrong, not for things that

were wrong and have been made right (in this case, back in 2009). Or

does anyone seriously claim that semantically an empty set is not equal

to another empty set?

In 7.7, there are only 8 Collection subclasses for which an empty

instance is not equal to another empty instance. 56 subclasses say they

are equal, and those are the central classes - 300,000 instances

compared to just 4,000 for the non-equality classes. I think the

non-equality classes should also be reconsidered, and perhaps answer

true too:

  instCount      class          (self new: 0) = (self new: 0)

1:  4010 -> MethodDictionary -> false

2:  25   -> ColorPreferencesDictionary -> false

3:  17   -> ExternalDictionary -> false

4:  4    -> StopsDictionary -> false

5:  1    -> PDPWeakCollection -> false

6:  1    -> PDPWeakDictionary -> false

7:  0    -> LinkedWeakAssociationDictionary -> false

8:  0    -> OrderedSet -> false

In addition, there is a bug in 7.6 and 7.7's Symbol (and concrete

subclasses), which allows "Symbol new: 0" and says it is not = to

another "Symbol new: 0". That's in contravention of Symbol's comment,

which says that if two Strings are =, then their Symbols are ==.

Steve

-----Original Message-----

From: [hidden email] [[hidden email]] On

Behalf Of Adams, Charles

Sent: 6. huhtikuuta 2011 17:37

To: Boris Popov, DeepCove Labs; Niall Ross

Cc: vwnc NC

Subject: Re: [vwnc] [VW 7.7] Dictionary>>=, Set>>=

Boris, that's just hyperbole. This misstep is unrelated to new

development.

Dictionary is a base Smalltalk class. It's history goes back decades.

Changing a base class' basic behavior is, IMHO, unreasonable. Add all

the new functionality you want, just don't mess with base classes. If

you don't like Dictionary>>=, extend Dictionary with

Dictionary>>noReallyEquals, or whatever. I did.

-----Original Message-----

From: Boris Popov, DeepCove Labs [[hidden email]]

Sent: Wednesday, April 06, 2011 9:27 AM

To: Adams, Charles; Niall Ross

Cc: vwnc NC

Subject: RE: [vwnc] [VW 7.7] Dictionary>>=, Set>>=

Ah, but now that it's been in the release for a while, how do you go

about not affecting code that now depends on new functionality? If we

all decide to never change anything, we may as well ask Cincom to

suspend development of new versions...

-Boris

-----Original Message-----

From: [hidden email] [[hidden email]] On

Behalf Of Adams, Charles

Sent: 06 April 2011 10:21

To: Niall Ross

Cc: vwnc NC

Subject: Re: [vwnc] [VW 7.7] Dictionary>>=, Set>>=

Since this change was made at customer request, I officially request,

as

a customer, that it be reverted.

-----Original Message-----

From: Niall Ross [[hidden email]]

Sent: Tuesday, April 05, 2011 2:32 PM

To: Adams, Charles

Cc: Randy Coulman; vwnc NC

Subject: Re: [vwnc] [VW 7.7] Dictionary>>=, Set>>=

Dear Charles,

I know for a fact it was in the list of Fixed ARs for that release,

because I made myself a note  to determine if this was an issue for

us

or not.  I realize that the Fixed AR list is not the release notes,

but

I definitely remember this change coming through where I saw it.

Randy

Yes

    46458    [Enh] Why not implement #= and #hash for Sets?

and related

    54829    Typo in Dictionary>>= comment

but in fact I'd agree that it also deserved a release notes para,

since

it does have potential to impact things unobviously.

[hidden email]> wrote:

I found no mention of Dictionary in the 7.7 or 7.7.1 release notes.

don't have the patience to search for "set".

I sympathise (I believe the entry for 'set' is the longest in the

Oxford

English Dictionary).  I confirm there is no Set>>= explanation there.

I'm guessing you feel you have an answer to the unfortunately-phrased

"Why not..." of the AR title - but in fact it was at customer request

that this change was made.

I understand the surprise at the old behavior. That doesn't mean

it's

ok to perturb production software.

Speaking theoretically, code that relies on identity should be using

==,

or an IdentitySet or similar for a collection where includes: is

relying

on identity.  Speaking practically, it's understandable that since ==

is

the default for =, this distinction is not always observed in old

code.

Some thoughts in my email to Sonia on how to detect.

             Yours faithfully

                   Niall Ross

_______________________________________________

vwnc mailing list

[hidden email]

http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________

vwnc mailing list

[hidden email]

http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________

vwnc mailing list

[hidden email]

http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________

vwnc mailing list

[hidden email]

http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

[hidden email]
April 6, 2011 11:38 AM

OK, so the base was semantically wrong, and has now been corrected.

Every new version brings up problems like this, breaking existing code.

Maybe this broke more code for some customers than other versions, maybe

even more code over all customers (which I doubt).

For those whose code did break, of course you have my sympathy. If you

really don't like it, the simplest thing may just be to override it back

to the old behavior. Some bits of the base image may stop working, but I

doubt there is a major problem. I just tried it, and no problem so far.

Let's send bug reports for things that are wrong, not for things that

were wrong and have been made right (in this case, back in 2009). Or

does anyone seriously claim that semantically an empty set is not equal

to another empty set?

In 7.7, there are only 8 Collection subclasses for which an empty

instance is not equal to another empty instance. 56 subclasses say they

are equal, and those are the central classes - 300,000 instances

compared to just 4,000 for the non-equality classes. I think the

non-equality classes should also be reconsidered, and perhaps answer

true too:

  instCount      class          (self new: 0) = (self new: 0)

1:  4010 -> MethodDictionary -> false

2:  25   -> ColorPreferencesDictionary -> false

3:  17   -> ExternalDictionary -> false

4:  4    -> StopsDictionary -> false

5:  1    -> PDPWeakCollection -> false

6:  1    -> PDPWeakDictionary -> false

7:  0    -> LinkedWeakAssociationDictionary -> false

8:  0    -> OrderedSet -> false

In addition, there is a bug in 7.6 and 7.7's Symbol (and concrete

subclasses), which allows "Symbol new: 0" and says it is not = to

another "Symbol new: 0". That's in contravention of Symbol's comment,

which says that if two Strings are =, then their Symbols are ==.

Steve

-----Original Message-----

From: [hidden email] [[hidden email]] On

Behalf Of Adams, Charles

Sent: 6. huhtikuuta 2011 17:37

To: Boris Popov, DeepCove Labs; Niall Ross

Cc: vwnc NC

Subject: Re: [vwnc] [VW 7.7] Dictionary>>=, Set>>=

Boris, that's just hyperbole. This misstep is unrelated to new

development.

Dictionary is a base Smalltalk class. It's history goes back decades.

Changing a base class' basic behavior is, IMHO, unreasonable. Add all

the new functionality you want, just don't mess with base classes. If

you don't like Dictionary>>=, extend Dictionary with

Dictionary>>noReallyEquals, or whatever. I did.

-----Original Message-----

From: Boris Popov, DeepCove Labs [[hidden email]]

Sent: Wednesday, April 06, 2011 9:27 AM

To: Adams, Charles; Niall Ross

Cc: vwnc NC

Subject: RE: [vwnc] [VW 7.7] Dictionary>>=, Set>>=

Ah, but now that it's been in the release for a while, how do you go

about not affecting code that now depends on new functionality? If we

all decide to never change anything, we may as well ask Cincom to

suspend development of new versions...

-Boris

-----Original Message-----

From: [hidden email] [[hidden email]] On

Behalf Of Adams, Charles

Sent: 06 April 2011 10:21

To: Niall Ross

Cc: vwnc NC

Subject: Re: [vwnc] [VW 7.7] Dictionary>>=, Set>>=

Since this change was made at customer request, I officially request,

as

a customer, that it be reverted.

-----Original Message-----

From: Niall Ross [[hidden email]]

Sent: Tuesday, April 05, 2011 2:32 PM

To: Adams, Charles

Cc: Randy Coulman; vwnc NC

Subject: Re: [vwnc] [VW 7.7] Dictionary>>=, Set>>=

Dear Charles,

I know for a fact it was in the list of Fixed ARs for that release,

because I made myself a note  to determine if this was an issue for

us

or not.  I realize that the Fixed AR list is not the release notes,

but

I definitely remember this change coming through where I saw it.

Randy

Yes

    46458    [Enh] Why not implement #= and #hash for Sets?

and related

    54829    Typo in Dictionary>>= comment

but in fact I'd agree that it also deserved a release notes para,

since

it does have potential to impact things unobviously.

[hidden email]> wrote:

I found no mention of Dictionary in the 7.7 or 7.7.1 release notes.

don't have the patience to search for "set".

I sympathise (I believe the entry for 'set' is the longest in the

Oxford

English Dictionary).  I confirm there is no Set>>= explanation there.

I'm guessing you feel you have an answer to the unfortunately-phrased

"Why not..." of the AR title - but in fact it was at customer request

that this change was made.

I understand the surprise at the old behavior. That doesn't mean

it's

ok to perturb production software.

Speaking theoretically, code that relies on identity should be using

==,

or an IdentitySet or similar for a collection where includes: is

relying

on identity.  Speaking practically, it's understandable that since ==

is

the default for =, this distinction is not always observed in old

code.

Some thoughts in my email to Sonia on how to detect.

             Yours faithfully

                   Niall Ross

_______________________________________________

vwnc mailing list

[hidden email]

http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________

vwnc mailing list

[hidden email]

http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________

vwnc mailing list

[hidden email]

http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

[hidden email]
April 6, 2011 10:37 AM

Boris, that's just hyperbole. This misstep is unrelated to new

development.

Dictionary is a base Smalltalk class. It's history goes back decades.

Changing a base class' basic behavior is, IMHO, unreasonable. Add all

the new functionality you want, just don't mess with base classes. If

you don't like Dictionary>>=, extend Dictionary with

Dictionary>>noReallyEquals, or whatever. I did.

-----Original Message-----

From: Boris Popov, DeepCove Labs [[hidden email]]

Sent: Wednesday, April 06, 2011 9:27 AM

To: Adams, Charles; Niall Ross

Cc: vwnc NC

Subject: RE: [vwnc] [VW 7.7] Dictionary>>=, Set>>=

Ah, but now that it's been in the release for a while, how do you go

about not affecting code that now depends on new functionality? If we

all decide to never change anything, we may as well ask Cincom to

suspend development of new versions...

-Boris

-----Original Message-----

From: [hidden email] [[hidden email]] On

Behalf Of Adams, Charles

Sent: 06 April 2011 10:21

To: Niall Ross

Cc: vwnc NC

Subject: Re: [vwnc] [VW 7.7] Dictionary>>=, Set>>=

Since this change was made at customer request, I officially request, as

a customer, that it be reverted.

-----Original Message-----

From: Niall Ross [[hidden email]]

Sent: Tuesday, April 05, 2011 2:32 PM

To: Adams, Charles

Cc: Randy Coulman; vwnc NC

Subject: Re: [vwnc] [VW 7.7] Dictionary>>=, Set>>=

Dear Charles,

I know for a fact it was in the list of Fixed ARs for that release,

because I made myself a note  to determine if this was an issue for us

or not.  I realize that the Fixed AR list is not the release notes, but

I definitely remember this change coming through where I saw it.

Randy

Yes

    46458    [Enh] Why not implement #= and #hash for Sets?

and related

    54829    Typo in Dictionary>>= comment

but in fact I'd agree that it also deserved a release notes para, since

it does have potential to impact things unobviously.

[hidden email]> wrote:

I found no mention of Dictionary in the 7.7 or 7.7.1 release notes. I

don't have the patience to search for "set".

I sympathise (I believe the entry for 'set' is the longest in the Oxford

English Dictionary).  I confirm there is no Set>>= explanation there.

I'm guessing you feel you have an answer to the unfortunately-phrased

"Why not..." of the AR title - but in fact it was at customer request

that this change was made.

I understand the surprise at the old behavior. That doesn't mean it's

ok to perturb production software.

Speaking theoretically, code that relies on identity should be using ==,

or an IdentitySet or similar for a collection where includes: is relying

on identity.  Speaking practically, it's understandable that since == is

the default for =, this distinction is not always observed in old code.

Some thoughts in my email to Sonia on how to detect.

             Yours faithfully

                   Niall Ross

_______________________________________________

vwnc mailing list

[hidden email]

http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________

vwnc mailing list

[hidden email]

http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

[hidden email]
April 6, 2011 10:26 AM

Ah, but now that it's been in the release for a while, how do you go

about not affecting code that now depends on new functionality? If we

all decide to never change anything, we may as well ask Cincom to

suspend development of new versions...

-Boris

-----Original Message-----

From: [hidden email] [[hidden email]] On

Behalf Of Adams, Charles

Sent: 06 April 2011 10:21

To: Niall Ross

Cc: vwnc NC

Subject: Re: [vwnc] [VW 7.7] Dictionary>>=, Set>>=

Since this change was made at customer request, I officially request, as

a customer, that it be reverted.

-----Original Message-----

From: Niall Ross [[hidden email]]

Sent: Tuesday, April 05, 2011 2:32 PM

To: Adams, Charles

Cc: Randy Coulman; vwnc NC

Subject: Re: [vwnc] [VW 7.7] Dictionary>>=, Set>>=

Dear Charles,

I know for a fact it was in the list of Fixed ARs for that release,

because I made myself a note  to determine if this was an issue for us

or not.  I realize that the Fixed AR list is not the release notes, but

I definitely remember this change coming through where I saw it.

Randy

Yes

    46458    [Enh] Why not implement #= and #hash for Sets?

and related

    54829    Typo in Dictionary>>= comment

but in fact I'd agree that it also deserved a release notes para, since

it does have potential to impact things unobviously.

[hidden email]> wrote:

I found no mention of Dictionary in the 7.7 or 7.7.1 release notes. I

don't have the patience to search for "set".

I sympathise (I believe the entry for 'set' is the longest in the Oxford

English Dictionary).  I confirm there is no Set>>= explanation there.

I'm guessing you feel you have an answer to the unfortunately-phrased

"Why not..." of the AR title - but in fact it was at customer request

that this change was made.

I understand the surprise at the old behavior. That doesn't mean it's

ok to perturb production software.

Speaking theoretically, code that relies on identity should be using ==,

or an IdentitySet or similar for a collection where includes: is relying

on identity.  Speaking practically, it's understandable that since == is

the default for =, this distinction is not always observed in old code.

Some thoughts in my email to Sonia on how to detect.

             Yours faithfully

                   Niall Ross

_______________________________________________

vwnc mailing list

[hidden email]

http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________

vwnc mailing list

[hidden email]

http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

[hidden email]
April 6, 2011 10:21 AM

Since this change was made at customer request, I officially request, as

a customer, that it be reverted.

-----Original Message-----

From: Niall Ross [[hidden email]]

Sent: Tuesday, April 05, 2011 2:32 PM

To: Adams, Charles

Cc: Randy Coulman; vwnc NC

Subject: Re: [vwnc] [VW 7.7] Dictionary>>=, Set>>=

Dear Charles,

I know for a fact it was in the list of Fixed ARs for that release,

because I made myself a note  to determine if this was an issue for us

or not.  I realize that the Fixed AR list is not the release notes, but

I definitely remember this change coming through where I saw it.

Randy

Yes

    46458    [Enh] Why not implement #= and #hash for Sets?

and related

    54829    Typo in Dictionary>>= comment

but in fact I'd agree that it also deserved a release notes para, since

it does have potential to impact things unobviously.

[hidden email]> wrote:

I found no mention of Dictionary in the 7.7 or 7.7.1 release notes. I

don't have the patience to search for "set".

I sympathise (I believe the entry for 'set' is the longest in the Oxford

English Dictionary).  I confirm there is no Set>>= explanation there.

I'm guessing you feel you have an answer to the unfortunately-phrased

"Why not..." of the AR title - but in fact it was at customer request

that this change was made.

I understand the surprise at the old behavior. That doesn't mean it's

ok to perturb production software.

Speaking theoretically, code that relies on identity should be using ==,

or an IdentitySet or similar for a collection where includes: is relying

on identity.  Speaking practically, it's understandable that since == is

the default for =, this distinction is not always observed in old code.

Some thoughts in my email to Sonia on how to detect.

             Yours faithfully

                   Niall Ross

_______________________________________________

vwnc mailing list

[hidden email]

http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

--
Alan Knight [|], Engineering Manager, Cincom Smalltalk
[hidden email]
[hidden email]
http://www.cincomsmalltalk.com

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Nicolas Cellier

Re: [VW 7.7] Dictionary>>=, Set>>=

In reply to this post by Alan Knight-2

Alan Knight <knight <at> acm.org> writes:

> I agree that we should have had that as a release note, and it would
> be good to provide assistance for people who might be affected by
> such problems. Obviously we can't possibly test all implications for
> customer implications, but providing migration assistance would be
> helpful. I do note that, for Sets, this appears to be a change that
> every other living Smalltalk dialect has also made, and for
> Dictionaries, all but VA. I think VA may be the only one in which
> Dictionary does not inherit from Set.

In Squeak/Pharo Association>>= was changed once to also test the value.
This made Dictionary behave differently than the original st-80 Set of
Association it ever was.
Now they both inherit from HashedCollection, but a Dictionary is no more a Set.

For those impacted by this change, would it make sense to subclass
Set/Dictionary and override = ?

With namespace import tricks maybe it could be transparent ?

Nicolas

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Chase, Sonia

Re: [VW 7.7] Dictionary>>=, Set>>=

Our concern with removing the change is wondering what code will break
that is now dependent on the new behavior. These problems will be as
difficult to determine as the ones that the new Dictionary>>= causes.

Sonia

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On
Behalf Of nicolas cellier
Sent: Thursday, April 07, 2011 3:48 PM
To: [hidden email]
Subject: Re: [vwnc] [VW 7.7] Dictionary>>=, Set>>=

Alan Knight <knight <at> acm.org> writes:

> I agree that we should have had that as a release note, and it
would
> be good to provide assistance for people who might be affected by
> such problems. Obviously we can't possibly test all implications
for
> customer implications, but providing migration assistance would be
> helpful. I do note that, for Sets, this appears to be a change
that
> every other living Smalltalk dialect has also made, and for
> Dictionaries, all but VA. I think VA may be the only one in which
> Dictionary does not inherit from Set.

In Squeak/Pharo Association>>= was changed once to also test the value.
This made Dictionary behave differently than the original st-80 Set of
Association it ever was.
Now they both inherit from HashedCollection, but a Dictionary is no more
a Set.

For those impacted by this change, would it make sense to subclass
Set/Dictionary and override = ?

With namespace import tricks maybe it could be transparent ?

Nicolas

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Nicolas Cellier

Re: [VW 7.7] Dictionary>>=, Set>>=

What I did in Squeak for instrumenting such method usage was to:

- raise a specific Notification if certain condition was met
self meetMySpecialCondition ifTrue: [MySpecificNotification raise].
- then used the old MessageTally to accumulate stack trace on an
emulated UI loop.
- then performed my favourite UI activities with a handler for
tallying each occurence of MySpecificNotification
- then display the stack trace after some amount of time or after a
specific action via a shared variable, a Semaphore, or something

A Squeak example was:

"INITIALIZE THE TALLY (that is hackish)"
tally := MessageTally new.
tally spyEvery: 100 on: ['em ezilaitini ot si siht' reverse].
tally class: World class method: World class>>#doOneCycle.

"ARM A TIMER TO END THE TALLY"
tallyEnd := false.
[(Delay forSeconds: 300) wait. tallyEnd := true] fork.

"EMULATE REGULAR SQUEAK USER ACTIVITY LOOP"
[[World doOneCycle. Processor yield. tallyEnd] whileFalse]
"TALLY THE CALL STACK AT EACH SENT OF YOUR METHODS"
on: YourNotification
do: [:exc | tally tally: exc signalerContext by: 1.
exc resume].

"OPEN A WINDOW WITH TALLY CALL STACK RESULTS"
(StringHolder new contents:
(String streamContents: [:s | tally report: s]))
openLabel: 'YourNotification Spy Results'.
tally close.

See http://www.mail-archive.com/beginners@.../msg04427.html

Maybe it's hard to transpose on VW multithreaded UI, and maybe
MessageTally has been replaced by more sophisticated tools...
But maybe it's worth a try... Seing the full stack gives great
insights on what's going on.

Nicolas

2011/4/7 Chase, Sonia <[hidden email]>:

> Our concern with removing the change is wondering what code will break
> that is now dependent on the new behavior. These problems will be as
> difficult to determine as the ones that the new Dictionary>>= causes.
>
> Sonia
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
> Behalf Of nicolas cellier
> Sent: Thursday, April 07, 2011 3:48 PM
> To: [hidden email]
> Subject: Re: [vwnc] [VW 7.7] Dictionary>>=, Set>>=
>
> Alan Knight <knight <at> acm.org> writes:
>
>> I agree that we should have had that as a release note, and it
> would
>> be good to provide assistance for people who might be affected by
>> such problems. Obviously we can't possibly test all implications
> for
>> customer implications, but providing migration assistance would be
>> helpful. I do note that, for Sets, this appears to be a change
> that
>> every other living Smalltalk dialect has also made, and for
>> Dictionaries, all but VA. I think VA may be the only one in which
>> Dictionary does not inherit from Set.
>
> In Squeak/Pharo Association>>= was changed once to also test the value.
> This made Dictionary behave differently than the original st-80 Set of
> Association it ever was.
> Now they both inherit from HashedCollection, but a Dictionary is no more
> a Set.
>
> For those impacted by this change, would it make sense to subclass
> Set/Dictionary and override = ?
>
> With namespace import tricks maybe it could be transparent ?
>
> Nicolas
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc