> There was a discussion about Dicts/Sets on squeak dev more than year > ago > http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-June/117840.html > > IMO making Dictionary a subclass of Set was mistake.
subclassing indeed is not really a good choice. > But there's little what can be done without risk of breaking many > code. Yes this is not the point. What we want to do is to build another library for Smalltalk 3000 :) > Some related problem - about letting Sets include nils and 'self' as > elements, also was discussed on squeak-dev. > It can be done w/o breaking much compatibility. I would love that this issue gets solved. As eliot pointed it out this could be done with one primitive been able to preallocate with a default value. Now I may be wrong. > > > 2008/12/30 nicolas cellier <[email protected]>: >> Sorry to repost, seems that gmane did not like my first attempt... >> >> >> Stéphane Ducasse <stephane.duca...@...> writes: >>> >>> >>> On Dec 29, 2008, at 12:23 PM, Alexandre Bergel wrote: >>> >>>> Dear List, >>>> >>>> I was wondering whether I am the only one shocked when I see this: >>>> >>>> (Set new add: #b -> 'B'; yourself) includes: #b -> 'B' ====> >>>> true >>>> (Set new add: #b -> 'B'; yourself) includes: 'B' ====> false >>> >>> this is correct >>> >>>> (Dictionary new add: #b -> 'B'; yourself) includes: #b -> 'B' >>>> ====> false >>>> (Dictionary new add: #b -> 'B'; yourself) includes: 'B' ====> >>>> true >>> >>> we should check the semantics of includes: >>> >>>> Dictionary inherits from Set. This means that if Set would have a >>>> contract, it would break in Dictionary. >>>> IMO, we should have >>>> (Dictionary new add: #b -> 'B'; yourself) includes: #b -> 'B' >>>> ====> >>>> true >>>> (Dictionary new add: #b -> 'B'; yourself) includes: 'B' ====> >> false >>>> >>>> No? >>> >>> Dictionary and Set relationship is subclassing so a lot can be >>> strange. >>> We should fix that in Bloc. >>> >> >> From the st80 origin, Dictionary is a Bag of values. >> Each value of this Bag is indexed with a unique key. >> >> It is a Bag because: >> a) multiple values can be in the dictionary: >> (Dictionary new) at: 'one' put: 1; at: 'first' put: 1; yourself. >> b) values are unordered: >> | d1 d2 | >> (d1 := Dictionary new: 3) at: 'one' put: 1; at: 'two' put: 2. >> (d2 := Dictionary new: 4) at: 'one' put: 1; at: 'two' put: 2. >> stream := (String new: 64) writeStream. >> d1 do: [:v | stream print: v; cr]. >> d2 do: [:v | stream print: v; cr]. >> stream contents. >> And as you can see, #do: does apply on values, as would #collect: >> #select: #reject: #includes: etc... >> >> The fact that Dictionary is implemented with Associations could be >> seen >> as a private implementation-defined feature. >> Though, by tradition, associationsDo: has been made a public >> interface, >> so as the possibility to directly add an Association. >> >> But semantically, Dictionary is not a Set of Associations. >> Example: >> (Set new) add: $a->65; add: $a->1; yourself. >> (Dictionary new) add: $a->65; add: $a->1; yourself. >> >> Dictionary could be viewed as a Set of keys. >> From that POV, it shared enough property with Set to be implemented >> as >> a subclass. That's all. >> I proposed once to detach Set and Dictionary and derive them from a >> common ancestor just for >> clarity... >> >> Nicolas >> >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
