[Cuis-dev] Dictionary

Phil (list) pbpublist at gmail.com
Thu Dec 31 18:32:35 CST 2015


Jonathan,

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
streamlined :-)

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
previous experience.

> 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
> represent 
> 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
> of 
> two perspectives: a set of associations, or a container of values
> that 
> are externally named where the name can be any object that responds
> to 
> =. The external name is referred to as the key.  I inherit many 
> operations from Set.
> 

Yes.

> (Dictionary) add: is in the "adding" category - not "private". There
> is 
> no warning against it's usage that I can see.
> 

Yes.  There have been previous discussions about marking things
private/public.

> (Object) -> anObject
>      "Answer an Association between self and anObject"
> 
> ... would seem to imply that an Association is something more than
> an 
> 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
> wrong 
> because I've had my head in BTrees for a few weeks.
> 
> I'm happy (well not really) to programme by agreement, but please,
> you 
> 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.

> Jonathan.
> 
> 

Phil




More information about the Cuis-dev mailing list