Problems and Dictionary>>copy-Bug in VW3 and VW7 
Author Message
 Problems and Dictionary>>copy-Bug in VW3 and VW7

1) Evaluate the following code:

| a b |
a := Dictionary new.
a at: 10 put: 'hello'.
b := a copy.
b at: 10 put: 'world'.
a at: 10

This gives 'world' instead of 'hello'. It is because Dictionary>>copy
doesn't
copy the associations. #remove and #at:put: with a new key work, but not
with an existing key.

Because the associations belong to the implementation of Dictionary they
have
to be copied also. An alternative would may be to create a new association
everytime #at:put: is called. Then the associations would be shared and the
sharing
would decrease gradually as the second dictionary is used (disadvantage is
the
a user might thing he could modify associations of a copied dictionary).

Amazing how long this bug was in VisualWorks. I suppose there is a lot of
software
out which copies and modifies dictionaries which are affected by this bug.

2) Also "Dictionary>>new: size" creates a dictionary which is not able to
hold
size elements without growing what most programmers would expect. To fix
this
it should read:

new: anInteger
 ^super new: anInteger + (anInteger // 3) + 1

to be compatible with the method #fullCheck on the instance side.

3) Why does Dictionary still use Associations, why is it not implemented
like IdentitySet?

Regards

Carsten



Sat, 23 Jul 2005 04:54:21 GMT  
 Problems and Dictionary>>copy-Bug in VW3 and VW7

Quote:

> 1) Evaluate the following code:

> | a b |
> a := Dictionary new.
> a at: 10 put: 'hello'.
> b := a copy.
> b at: 10 put: 'world'.
> a at: 10

> This gives 'world' instead of 'hello'. It is because Dictionary>>copy
> doesn't
> copy the associations. #remove and #at:put: with a new key work, but not
> with an existing key.

Good observation.  The Dictionary class should have a postCopy method
which copies the associations.

Quote:
> 2) Also "Dictionary>>new: size" creates a dictionary which is not able to
> hold
> size elements without growing what most programmers would expect. To fix
> this
> it should read:

> new: anInteger
>  ^super new: anInteger + (anInteger // 3) + 1

> to be compatible with the method #fullCheck on the instance side.

Actually, I would expect that Dictionary new: size would not be able to
hold "size" elements.  I would expect that this is the size of the hash
table.

Quote:
> 3) Why does Dictionary still use Associations, why is it not implemented
> like IdentitySet?

When compiled methods reference other classes or globals, they actually
reference the association in the Smalltalk dictionary. This way, when
the class changes shape, the reference still works. Things have changed
a bit with the introduction of namespaces, but this was how things
worked for a long time.

David Buck
Simberon Inc.
www.simberon.com



Sat, 23 Jul 2005 05:05:37 GMT  
 Problems and Dictionary>>copy-Bug in VW3 and VW7

Quote:

> > 1) Evaluate the following code:

> > | a b |
> > a := Dictionary new.
> > a at: 10 put: 'hello'.
> > b := a copy.
> > b at: 10 put: 'world'.
> > a at: 10

> > This gives 'world' instead of 'hello'. It is because Dictionary>>copy
> > doesn't
> > copy the associations. #remove and #at:put: with a new key work, but not
> > with an existing key.

> Good observation.  The Dictionary class should have a postCopy method
> which copies the associations.

This depends on whether you consider a dictionary as a collection of
associations or as key/value map. If you think that a dictionary is a
collection of associations, then it makes sense to not copy the associations
when the dictionary is copied. Other collections don't copy their elements
so why should dictionaries?

However, if you consider a dictionary as a key/value map then you should
copy the association since they are just internal details. Of course, if you
believe that associations are just internal details, all of the association
methods in dictionary should be removed or made private.

I prefer the view of dictionaries being key/value maps, but VA, VW, &
Dolphin all take the other approach. They all return 'world' instead of
'hello'. Of course, all of these fail to work when you use an identity
dictionary:
    | dictionary association |
    dictionary := IdentityDictionary new.
    association := 1 -> 2.
    dictionary add: association.
    association value: 3.
    dictionary at: 1
If they really consider dictionaries as collections of associations, then
this should return 3. However, all of them return 2.

John Brant



Sat, 23 Jul 2005 06:16:41 GMT  
 Problems and Dictionary>>copy-Bug in VW3 and VW7

Quote:
> I prefer the view of dictionaries being key/value maps, but VA, VW, &
> Dolphin all take the other approach.

But many in turn have a LookupTable (or something like that) class
that uses #=/#hash for equality but work as key/value maps as
expected.  There are also memory and performance savings if the
dictionary is not too sparse.

Paolo



Sat, 23 Jul 2005 19:30:01 GMT  
 Problems and Dictionary>>copy-Bug in VW3 and VW7

Quote:

> This depends on whether you consider a dictionary as a collection of
> associations or as key/value map.
[snip]
>If they really consider dictionaries as collections of associations, then
> this should return 3. However, all of them return 2.

John,

I was under the impression that a dictionary is neither a key/value map, nor
a collection of associations. Instead it is a collection of the values,
which is indexed by arbitrary keys as opposed to just integers, as in an
array. I'm pretty sure I have that impression from the Blue Book.

Considering that a collection behaviorally means firstly membership and
secondly enumerability, includes: and do: are then expected to look at the
values, and I suppose that is in fact how they work. This is not to say I'm
not interested in other points of view, in fact I welcome them!

Regards,

Peter van Rooijen
Amsterdam



Sun, 24 Jul 2005 09:04:35 GMT  
 Problems and Dictionary>>copy-Bug in VW3 and VW7

Quote:


> > 1) Evaluate the following code:

> > | a b |
> > a := Dictionary new.
> > a at: 10 put: 'hello'.
> > b := a copy.
> > b at: 10 put: 'world'.
> > a at: 10

> > This gives 'world' instead of 'hello'. It is because Dictionary>>copy
> > doesn't
> > copy the associations. #remove and #at:put: with a new key work, but not
> > with an existing key.

> Good observation.  The Dictionary class should have a postCopy method
> which copies the associations.

No!  This will *break* huge amounts of code.  Alas changing the
implementation of Dictionary>>copy will take a thorough review of VW's
code base.  For now the work-around is to use
        Dictionary>>#copyWithCopiedValues

--
_______________,,,^..^,,,____________________________
Eliot Miranda              Smalltalk - Scene not herd



Mon, 25 Jul 2005 04:37:28 GMT  
 Problems and Dictionary>>copy-Bug in VW3 and VW7

Quote:



> > > 1) Evaluate the following code:

> > > | a b |
> > > a := Dictionary new.
> > > a at: 10 put: 'hello'.
> > > b := a copy.
> > > b at: 10 put: 'world'.
> > > a at: 10

> > > This gives 'world' instead of 'hello'. It is because Dictionary>>copy

> > > doesn't
> > > copy the associations. #remove and #at:put: with a new key work, but
>  not
> > > with an existing key.

> > Good observation.  The Dictionary class should have a postCopy method
> > which copies the associations.

> No!  This will *break* huge amounts of code.  Alas changing the
> implementation of Dictionary>>copy will take a thorough review of VW's
> code base.  For now the work-around is to use
>    Dictionary>>#copyWithCopiedValues

No, that copies the associatiations *and* the values.  In VW (up to
VW7) there appears to be no convenient way of copying the associations
short of something like "Dictionary new addAll: (aDictionary
associations collect: [:a | a copy]); yourself".


Mon, 25 Jul 2005 10:12:37 GMT  
 Problems and Dictionary>>copy-Bug in VW3 and VW7

Quote:




> > > > 1) Evaluate the following code:

> > > > | a b |
> > > > a := Dictionary new.
> > > > a at: 10 put: 'hello'.
> > > > b := a copy.
> > > > b at: 10 put: 'world'.
> > > > a at: 10

> > > > This gives 'world' instead of 'hello'. It is because Dictionary>>copy

> > > > doesn't
> > > > copy the associations. #remove and #at:put: with a new key work, but
> >  not
> > > > with an existing key.

> > > Good observation.  The Dictionary class should have a postCopy method
> > > which copies the associations.

> > No!  This will *break* huge amounts of code.  Alas changing the
> > implementation of Dictionary>>copy will take a thorough review of VW's
> > code base.  For now the work-around is to use
> >       Dictionary>>#copyWithCopiedValues

> No, that copies the associatiations *and* the values.  In VW (up to
> VW7) there appears to be no convenient way of copying the associations
> short of something like "Dictionary new addAll: (aDictionary
> associations collect: [:a | a copy]); yourself".

Good point.  OK, then copy the schema...

Dictionary methods for copying
copyAssociations
    ^self shallowCopy postCopyAssociations

postCopyAssociations
    self postCopy.
    1 to: self basicSize do:
        [:i| | thing |
        thing := self basicAt: i.
        thing ~~ nil ifTrue:
                [self basicAt: i put: thing shallowCopy]]

--
_______________,,,^..^,,,____________________________
Eliot Miranda              Smalltalk - Scene not herd



Mon, 25 Jul 2005 10:52:07 GMT  
 
 [ 8 post ] 

 Relevant Pages 

1. Bugs in ST80 4.1 (Stream>>through, List>>copyFrom:to:)

2. HELP>>>>>>>Fortran-Pascal Linking

3. Collection>>addAll: problems on Dictionaries

4. >>>>>>>FROM SMTK TO C++

5. *** COPIED FROM: >>>Usenet/comp.arch.embe 3009 lfoss@cix.comp(1712)13Nov95 21:47

6. WIN32S 1.30 problem with File class>>copy:to: in large VSEW301 image

7. ><><><><>Heeeeeeeeeeeeeeelp on INT 14!><><><><><>

8. <<<<<YOU MUST CHECK THIS OUT >>>>>>>>>> 2103

9. >>>>>AVL tree

10. >>>>>How to read a IMAGE file?(BMP, GIF)|||||||||

11. ANNOUNCE>>>>>TOTAL FrameWork from Cincom

12. Slow/No Speed>>>>>>>>>

 

 
Powered by phpBB® Forum Software