pbpublist at gmail.com
Thu Dec 31 18:32:35 CST 2015
On Fri, 2016-01-01 at 09:47 +1100, Jonathan Kelly via Cuis-dev wrote:
> On 01-Jan-16 6:47 AM, Phil (list) via Cuis-dev wrote:
> > >
> > An Association is just an implementation detail (i.e. the storage
> > mechanism the Dictionary uses), all the Dictionary promises to do
> > is
> > store an arbitrary object given a distinct key value (as determined
> > by
> > #=), not distinct Associations. It doesn't promise to use the
> > Association, or even the key, you pass it. This is actually what
> > most
> > people want it do do the majority of the time. If what you need is
> > distinctiveness test to be based on the key identity, then you use
> > IdentityDictionary (which uses #==) If you look at #scanFor: in
> > both
> > *Dictionary classes you'll see the difference and notice that
> > neither
> > one cares about the Association, only its key. If what you are
> > looking
> > for is a collection of unique associations, then what you probably
> > want
> > to use is an IdentitySet for your associations.
> > > - Dan
> > >
> > >
> > > _______________________________________________
> > > Cuis-dev mailing list
> > > Cuis-dev at cuis-smalltalk.org
> > > http://cuis-smalltalk.org/mailman/listinfo/cuis-dev_cuis-smalltal
> > > k.or
> > > g
> > _______________________________________________
> > Cuis-dev mailing list
> > Cuis-dev at cuis-smalltalk.org
> > http://cuis-smalltalk.org/mailman/listinfo/cuis-dev_cuis-smalltalk.
> > org
> Have you heard of the term "defensive programming"?
> You've made a case, but how would anyone know that is the intended
> (devalued) usage of Associations?
I had a long and opinionated piece ready to click send on but then I
I suggested the devalued status of methods dealing with Associations
based on a previous experience in Cuis with Dictionary and Association.
It isn't officially devalued or deprecated, but 'feels' to me like
something that could easily disappear at some point based on my
> Here's my case to the contrary:
> LookupKey : I represent a key for looking up entries in a data
> structure. Subclasses of me, such as Association, typically
> dictionary entries.
> Association: I represent a pair of associated objects--a key and a
> value. My instances can serve as entries in a dictionary.
> Dictionary: I represent a set of elements that can be viewed from one
> two perspectives: a set of associations, or a container of values
> are externally named where the name can be any object that responds
> =. The external name is referred to as the key. I inherit many
> operations from Set.
> (Dictionary) add: is in the "adding" category - not "private". There
> no warning against it's usage that I can see.
Yes. There have been previous discussions about marking things
> (Object) -> anObject
> "Answer an Association between self and anObject"
> ... would seem to imply that an Association is something more than
> implementation detail.
My words, no one else's. (i.e. I do not speak on behalf of Squeak, Cuis
or anyone other than myself)
> Oh, I don't have a usage ... I was looking at the code trying to
> understand the Dictionary protocol and saw something that looked
> because I've had my head in BTrees for a few weeks.
> I'm happy (well not really) to programme by agreement, but please,
> have to let me know what the agreements are! :)
I agree with the sentiment, but in practice that's not how I've found
things to work in the Squeak-derivative world.
More information about the Cuis-dev