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

_______________________________________________
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

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.
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

While we understand the need for backward compatibility, the fact that all of the internals are visible in source and that API's and behaviour were not particularly clearly defined means that almost any change can potentially perturb production software. I don't believe we've had any previous reports of problems due to that change, and it seems that almost all other Smalltalk dialects (VA also has this behaviour) have made similar changes. It's more consistent with the behaviour of other collections, and allows sets, dictionaries, and their relatives to be used in hashed collections themselves.

---

[hidden email]
April 4, 2011 6:35 PM

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 understand the surprise at the old behavior. That doesn’t mean it’s ok to perturb production software.

 

 

 

 

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

---

[hidden email]
April 4, 2011 5:39 PM

I'll let others discuss pitfalls or reasoning. Is it the case that no mention was made of Dictionary change, but a mention was made of Set change?

I do know that at times over the years, I had been surprised/burned by the old behavior.

I do know that as of today, the latest releases of the following dialects behave as follows for the Dictionary expression:

VW -> true

GST -> true

ST/X -> true

Dolpin -> false

VA -> ?

Squeak (Pharo) -> true

--

Travis Griggs

Objologist

"An idea, like a ghost, must be spoken to a little before it will explain itself." - Charles Dickens 

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

---

[hidden email]
April 4, 2011 3:45 PM

Before VW 7.7, Dictionary new ~= Dictionary new. Since VW 7.7, Dictionary new = Dictionary new.

 

Two questions:

1.    Has anyone (else) had a problem with this?

2.    Why was this released?

 

Dictionary, as a Smalltalk class, has been around since Smalltalk-80 and Smalltalk/V. AFAIK, Dictionary>>= has never been implemented this way; it has always inherited its implementation from Object>>=. I wonder about the cause behind this change. Why now? Is it in pursuit of some sort of standards compliance?

 

BTW, Set was changed in much the same way. There was no mention of these changes in the release notes.

 

_______________________________________________
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

In addition, if I might add, the old behavior is still available by
using #==.  If code was originally using #= as if it was (and meaning to
use) #==, then perhaps the code would be more clear if it was written to
use #== instead of #=.

The availability of equality testing that is not defined in terms of
identity makes it easier to compare sets at the end of tests.  For
example, something like

   self assert: self class selectors = self expectedSelectors

Without set / dictionary comparison, you'd have to write things like

   self class selectors asSortedCollection = self expectedSelectors
asSortedCollection

or similar, which are significantly slower.  For example, in a
workspace, evaluate:

s1 := self class selectors.
s2 := s1 copy.

Time millisecondsToRun: [200000 timesRepeat: [s1 = s2]] 1206

Time millisecondsToRun: [1000 timesRepeat: [| ss | ss := s1
asSortedCollection.  ss = ss]] 1485

Note that the second timesRepeat: is doing 200 times less work, ouch.
With integers, the effect is not that obvious because sorting is
cheaper, but direct comparison is faster by a factor of about 3x...

t1 := s1 collect: [:x | x identityHash].
t2 := t1 copy.

Time millisecondsToRun: [200000 timesRepeat: [t1 = t2]] 1177

Time millisecondsToRun: [200000 timesRepeat: [| tt | tt := t1
asSortedCollection.  tt = tt]] 3207

Andres.

On 4/4/2011 4:31 PM, Alan Knight wrote: _______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Just FYI

>I do know that as of today, the latest releases of the following dialects behave as follows for the Dictionary expression:
>
>VW -> true
>GST -> true
>ST/X -> true
>Dolphin -> false
>VA -> ?
>  
>
VASmalltalk 8.0.2 returns false for Dictionary.  However Set new = Set
new returns true there.

>Squeak (Pharo) -> true
>

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

Our problem with the change is that it is in a base class and is causing
problems in code that was written with the old behavior and has been
working for years.  

We discovered the problem when we were trying to figure out why when we
set the selection in an IndentedTreeSelectionInList to the empty
Dictionary we had just added to the tree that the selection was actually
being set to another empty Dictionary in the tree.   The two empty
dictionaries were previously not equal, now they are equal.  Cincom is
working with us to resolve this problem.

Finding this error made us concerned about where else this change is
affecting our code and Cincom's.  It is not an easy change to isolate
and it is causing us to review all of our code that we have written over
the past 20 years.  We deliver a framework to our customers so we also
have a responsibility to tell them how to detect the problems this
change will have on their code as well.  

Yes, we can change an "=" to a "==", but we have to first find all of
the places "=" is used with dictionaries.   The change also causes
problems when you use includes: with a collection that contains
dictionaries.  We have successfully replaced the use of includes: with
an anySatisfy: block that uses a "==" check to get the old behavior.
The individual fixes are not difficult; it is the detection of where the
change is causing a problem that is difficult.

We sent our original note because we couldn't believe that this change
to Dictionary didn't cause problems for others too when they ported to
7.7.  This is a fundamental change to a base class and whether or not
you agree the change should have been made, it will affect your code.

We would like to search the code to find where it is affected by this
change to avoid an expensive error not found until it scraps wafers on
one of our customer's tools.  We have explored Transcript writes in the
Dictionary>>"=" method, but it is difficult to print something that
tells us the calling chain without dumping the entire stack.

Sonia Chase


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On
Behalf Of Andres Valloud
Sent: Monday, April 04, 2011 6:53 PM
To: [hidden email]
Subject: Re: [vwnc] [VW 7.7] Dictionary>>=, Set>>=

In addition, if I might add, the old behavior is still available by
using #==.  If code was originally using #= as if it was (and meaning to

use) #==, then perhaps the code would be more clear if it was written to

use #== instead of #=.

The availability of equality testing that is not defined in terms of
identity makes it easier to compare sets at the end of tests.  For
example, something like

   self assert: self class selectors = self expectedSelectors

Without set / dictionary comparison, you'd have to write things like

   self class selectors asSortedCollection = self expectedSelectors
asSortedCollection

or similar, which are significantly slower.  For example, in a
workspace, evaluate:

s1 := self class selectors.
s2 := s1 copy.

Time millisecondsToRun: [200000 timesRepeat: [s1 = s2]] 1206

Time millisecondsToRun: [1000 timesRepeat: [| ss | ss := s1
asSortedCollection.  ss = ss]] 1485

Note that the second timesRepeat: is doing 200 times less work, ouch.
With integers, the effect is not that obvious because sorting is
cheaper, but direct comparison is faster by a factor of about 3x...

t1 := s1 collect: [:x | x identityHash].
t2 := t1 copy.

Time millisecondsToRun: [200000 timesRepeat: [t1 = t2]] 1177

Time millisecondsToRun: [200000 timesRepeat: [| tt | tt := t1
asSortedCollection.  tt = tt]] 3207

Andres.

On 4/4/2011 4:31 PM, Alan Knight wrote:
> While we understand the need for backward compatibility, the fact that
> all of the internals are visible in source and that API's and
behaviour
> were not particularly clearly defined means that almost any change can
> potentially perturb production software. I don't believe we've had any
> previous reports of problems due to that change, and it seems that
> almost all other Smalltalk dialects (VA also has this behaviour) have
> made similar changes. It's more consistent with the behaviour of other
> collections, and allows sets, dictionaries, and their relatives to be
> used in hashed collections themselves.
>
>>
------------------------------------------------------------------------ ------------------------------------------------------------------------ by ------------------------------------------------------------------------ _______________________________________________
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

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

Dear Sonia,

>We would like to search the code to find where it is affected by this
>change to avoid an expensive error not found until it scraps wafers on
>one of our customer's tools.  We have explored Transcript writes in the
>Dictionary>>"=" method, but it is difficult to print something that
>tells us the calling chain without dumping the entire stack.
>  
>
_Very_ tentatively (because you would have to code in them, not just use
them out of the box), I mention the RBDynamicRenaming parcels, and/or
Method Wrappers generally.  You may find it a lot easier and more
understandable just to instrument Dictionary>>= as you are doing -
method wrappers can be alarming things to use.  But if you need to
detect with first-match-rewrites-caller or similar (because there's a
performance impact of the instrumentation), or to have something you can
install and uninstall in your client's test rig, these _might_ offer
options.

Your condition is (I guess):

1) A Dictionary is being compared to another by =.

2) The dictionaries are not ==.

3) The code is yours (detected by its being owned by your packages, not
base ones, or by its coder, or by its date or otherwise).

4) Both dictionaries are empty (because you are sure that accidental
equality of non-empty is not a practical concern) or maybe you don't
want to assume this last condition.

Thus to find all cases where identity is in fact the intent.

             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

May be off tangent.

But something like this I think wb nice:
    a @= b

e.g.
    'key1' @= #key1

also
dictionary atLoosely: 'key1'
dictionary atLoosely: #key1

On the modeling object end, can't think of too many, if any times, we've
been interested in the diff. between 'key1' and #key2 (i.e. the dictionary
keys are homogeneous). Shouldn't have to worry about coercing key types, I
don't think.

thx,

gp




----- Original Message -----
From: "Andres Valloud" <[hidden email]>
To: <[hidden email]>
Sent: Monday, April 04, 2011 6:52 PM
Subject: Re: [vwnc] [VW 7.7] Dictionary>>=, Set>>=


In addition, if I might add, the old behavior is still available by
using #==.  If code was originally using #= as if it was (and meaning to
use) #==, then perhaps the code would be more clear if it was written to
use #== instead of #=.

The availability of equality testing that is not defined in terms of
identity makes it easier to compare sets at the end of tests.  For
example, something like

   self assert: self class selectors = self expectedSelectors

Without set / dictionary comparison, you'd have to write things like

   self class selectors asSortedCollection = self expectedSelectors
asSortedCollection

or similar, which are significantly slower.  For example, in a
workspace, evaluate:

s1 := self class selectors.
s2 := s1 copy.

Time millisecondsToRun: [200000 timesRepeat: [s1 = s2]] 1206

Time millisecondsToRun: [1000 timesRepeat: [| ss | ss := s1
asSortedCollection.  ss = ss]] 1485

Note that the second timesRepeat: is doing 200 times less work, ouch.
With integers, the effect is not that obvious because sorting is
cheaper, but direct comparison is faster by a factor of about 3x...

t1 := s1 collect: [:x | x identityHash].
t2 := t1 copy.

Time millisecondsToRun: [200000 timesRepeat: [t1 = t2]] 1177

Time millisecondsToRun: [200000 timesRepeat: [| tt | tt := t1
asSortedCollection.  tt = tt]] 3207

Andres.

On 4/4/2011 4:31 PM, Alan Knight wrote: _______________________________________________
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

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

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

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

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>
===========================================================

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

... as well as provide snippets of code to help folks trace occurrences
of these sends in their own code via combination of rewrite rules and
method wrapper traces, say in a workspace file or helper parcel.

-Boris

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On
Behalf Of Terry Raymond
Sent: 06 April 2011 11:17
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>
=========================================================== there. in old code.

_______________________________________________
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

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
us 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 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.
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

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.


-----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>
=========================================================== there. in old code.

_______________________________________________
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

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] [mailto:[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
us 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 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.
_______________________________________________
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