Dictionary>>addAll:

Hi,

I wonder what is illegal with adding the elements of a Dictionary to
another,
since Dolphin & VW & Squeak all raise an exception.

d1 := Dictionary new.
(1 to: 1000) do:[:i |
d1 add: i -> ('fooRecord #',i printString)].

d2 := Dictionary new.
(1001 to: 2000) do:[:i |
d2 add: i -> ('barRecord #',i displayString)].

d1 addAll: d2 ==> Exception: Message not understood: key#

Bye
Ingo

P.S. I know *why* they throw the exception, but what is illegal with it ?

Ingo,

> P.S. I know *why* they throw the exception, but what is illegal with it ?

It's not illegal as such, it's just not the default.

#addAll: iterates over the Dictionary passed as an argument using it's
default #do: selector and sending #add: to the receiver Dictionary with each
iteree. For things like OrderedCollections and SortedCollections that is
easy enough, it is obvious what the #do: loop should iterate over. For
Dictionaries it is more complex as #do: could legitimately iterate over the
keys, the values or the associations.  Equivalent to -

aDictionary keysDo: [:

or

aDictionary valuesDo: [

or

aDictionary associationsDo: [

The Blue Book (p151) states that the second choice, iterating over the
Dictionary values, is the default (as the most common/useful?) so that
became the default for the Dictionary #do: selector in all (?)
implementations and #valuesDo: is not (never?) implemented.  If you want
keys or associations you have to explicitly make the choice, and your
example only works if you specify associations.

d1 addAll: d2 associations

or the equivalent, and probably more efficient

d2 associationsDo: [:each | d1 add: each]

Personally I would have thought that a default of iterating over
associations was the better choice, but I expect I'm missing something <g>

Regards
    Ian

Ian,

> Personally I would have thought that a default of iterating over
> associations was the better choice, but I expect I'm missing something <g>

This has bothered me at times too, but, I think that the Blue Book has it
right.  Including the keys or associations is getting more into the storage
details than simply which elements are stored, and a separate iteration
message to get to that level of detail seems appropriate.  Fair?  Or are you
thinking more of the details of #addAll:, and maybe that some double
dispatch could end up picking the right selector to make it work out of the
box?

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill,

> This has bothered me at times too, but, I think that the Blue Book has it
> right.  Including the keys or associations is getting more into the
> storage details than simply which elements are stored, and a separate
>  iteration message to get to that level of detail seems appropriate.
> Fair?

Yes. If you did use #associationsDo: in the default #do: loop for
Dictionaries then you probably wouldn't want to do the same for LookupTable
(which don't maintain the key-value ralationship as an Association). As you
say, using #valuesDo: as the default avoids getting involved in these
storage, and other, details.

>              Or are you
> thinking more of the details of #addAll:, and maybe that some double
> dispatch could end up picking the right selector to make it work out of
> the box?

I was just really musing about the fact that when I iterate over a
Dictionary I quite often (but not always) want the Association rather than
just the plain value.  Thinking about it a bit more though I suppose that it
would be better to use an OrderedCollection of Associations (rather than a
Dictionary or LookupTable) in situations where I need the Association and,
more importantly, want to maintain the identity relationship between
Associations in different Collections.

Regards
    Ian

"Ian Bartholomew" <[hidden email]> schrieb im Newsbeitrag
news:9gdus6$8lpvs$[hidden email]...
> Ingo,
>
> > P.S. I know *why* they throw the exception, but what is illegal with it
?
>
> It's not illegal as such, it's just not the default.
>
> #addAll: iterates over the Dictionary passed as an argument using it's
> default #do: selector and sending #add: to the receiver Dictionary with
each
> iteree. For things like OrderedCollections and SortedCollections that is
> easy enough, it is obvious what the #do: loop should iterate over. For
> Dictionaries it is more complex as #do: could legitimately iterate over
the
Ian,

I'm somewhat surprised, because IMHO it's a contradiction to  OO uniformity
and
information/implementation hiding principles.

A simple overwritten

Dictionary>>addAll: aDictionary
^super addAll: aDictonary associations

and the OO world is in balance again.
Or am I wrong ?

Ingo

Ingo,

> A simple overwritten
>
> Dictionary>>addAll: aDictionary
> ^super addAll: aDictonary associations

I *think* I'd support the addition.  I don't think it's unreasonable to
expect the argument to #addAll: to be an object with a similar "flavour" to
the reciever.

However, I think a better implementation would be:

Dictionary>>addAll: aCollection
    aCollection keysAndValuesDo:
        [:key :value | self at: key put: value].

Since #keysAndValuesDo: seems more fundamental to me than #associations.  It
also avoids the problems with identity that Association objects drag in with
them.

The same might go for Dictionary class>>withAll:, however the Dictionary
class>>with:(with:)* methods confuse the picture since they would naturally
take an Association, so you'd expect the #withAll: method to take a
Collection of Associations.  Hmmm...

> Ingo

    -- chris

Ingo,

No, although I probably wouldn't do it that way as it is a bit inefficient,
especially when taking subclasses into account. LookupTable would be very
slow.

Other observations - in no particular order.

------

As with many "missing" methods in Smalltalk images it may just be a victim
of the eXtreme programming YAGNI (You Aint Gonna Need It) principle . Unless
you have a use for the method in the current image then don't bother
providing (or overriding in this case) it.

------

Maintaining Dictionaries using #add operations on Associations is, IMHO,
slightly dangerous.  It means that you have to know how a Dictionary was
created before performing certain operations on it, violating the
information/implementation hiding principles you mention above -

This is the behaviour I would expect from a Dictionary ...
d1 := Dictionary new.
d2 := Dictionary new.
d1 at: 1 put: 'hello'.
d2 at: 1 put: 'hello'.
d1 at: 1 put: 'goodbye'.
d2 at: 1 ===> 'hello'

... but by using #add: you get
d1 := Dictionary new.
d2 := Dictionary new.
d1 at: 1 put: 'hello'.
d2 addAll: d1 associations.
d1 at: 1 put: 'goodbye'.
d2 at: 1 ===> 'goodbye'

I know that the second example, Identical Associations in different
Dictionaries, is the behaviour that you sometimes want so I'm not saying
"never use #add:". It's just that it is the uncommon mode of operation and
your #addAll: might cause problems.

------

As I said to Bill in the other thread. If you want to maintain Collections
of Associations then it's probably better to use an OrderedCollection rather
than a Dictionary.

Regards
    Ian

"Chris Uppal" <[hidden email]> schrieb im
Newsbeitrag news:[hidden email]...
> Ingo,
>
> > A simple overwritten
> >
> > Dictionary>>addAll: aDictionary
> > ^super addAll: aDictonary associations
>
> I *think* I'd support the addition.  I don't think it's unreasonable to
> expect the argument to #addAll: to be an object with a similar "flavour"
to
> the reciever.
>
> However, I think a better implementation would be:
>
> Dictionary>>addAll: aCollection
>     aCollection keysAndValuesDo:
>         [:key :value | self at: key put: value].
>
> Since #keysAndValuesDo: seems more fundamental to me than #associations.
It
> also avoids the problems with identity that Association objects drag in
with
> them.
>
> The same might go for Dictionary class>>withAll:, however the Dictionary
> class>>with:(with:)* methods confuse the picture since they would
naturally
> take an Association, so you'd expect the #withAll: method to take a
> Collection of Associations.  Hmmm...
>
> > Ingo
>
>     -- chris
>
Chris,

you are right.
Using an implementation, that uses add: is dangerous, and indeed fails.
(-> Pool*Dictionary)

But this seems to be general enough:

addAll: aDictionary

aDictionary keysAndValuesDo: [:k :v|
| tmpVal |

tmpVal := self at: k ifAbsent:[nil].
tmpVal isNil
   ifTrue:[self at: k put: v]
  ifFalse:[ tmpVal = v ifFalse:[ ^self error: 'key collision would lead to
nondeterministic dictionary']]

].
^aDictionary


Ingo

Ingo,

I don't really see why you avoid overwriting existing entries.  To me it
seems just as natural to do so (it is, at worst, no more suprising to
overwrite the old entries than it would be to loose the new versions), and
is easier to code and will run faster.

> Ingo

    -- chris

Ian Bartholomew wrote:

> As I said to Bill in the other thread. If you want to maintain Collections
> of Associations then it's probably better to use an OrderedCollection rather
> than a Dictionary.

Can somebody refer me to a general source that covers the concepts of
collections/dictionaries  - irrespective of language. I'm not looking for
coding, but business examples of their application. (I realize that
Simula/Smalltalk are where 'it started' but a general source would be useful).

- Bag - I haven't currently found a specific use for these - preferring at the
moment to use Ordered/Sorted Collections

- Ordered/Sorted - for preference I go for Sorted - my prime use being
listboxes/droplists, but there are others.

- Dictionaries - at the moment I have used them for converting data files from
one data source to another - specifically, replacing separate files of codes
with one file containing 'universal codes' - the dictionary look-up allowing me
to test the incoming 'description' and then generate a new description record
with a mnemonic code.

Jimmy, Calgary AB

My favourite book for describing the collection classes is Smalltalk
by Example by Alec Sharp. He discusses the particulars of the
different collections and performance issues related to them. As his
book is written for VW (I believe 2.5), not all of the available
collections in Dolphin are described (ListModel, IdentityDictionary,
...) but still it gives you a good starting point. From there, explore
the class comment in Dolphin and you know exactly which one to use in
which occasion.

http://www.amazon.com/exec/obidos/ASIN/0079130364/qid=993196459/sr=1-35/ref=sc_b_35/102-2319523-4931366

Ted


>
> Jimmy, Calgary AB

Jimmy,

> Can somebody refer me to a general source that covers the concepts of
> collections/dictionaries  - irrespective of language. I'm not looking for
> coding, but business examples of their application.

 From a Smalltalk viewpoint ...

I think you'll have a problem finding something like this as there are no
hard and fast rules about the sort of collection type to use, there is often
no right and wrong. Each collection has it's own attributes and you have to
decide which is closest in relation to the context of the application.

Once you get to know each collection's attributes then it becomes reasonably
easy to know which situation requires which type of collection. For example,
you mentioned always using OrderedCollections rather than Bags. If the
context is a small collection then it won't matter but if you have a large
collection then lookup in a Bag is much (much) more efficient than an
OrderedCollection (assuming that an ordering of the elements is not needed).

Another difficulty with providing examples is that collection types are not
fixed. Creating an OrderedCollection, adding elements sequentially and the
converting to a SortedCollection can, depending on the context, be better
that starting with a SortedCollection.

Ian

Jimmy,

> Can somebody refer me to a general source that covers the concepts of
> collections/dictionaries  - irrespective of language. I'm not looking for
> coding, but business examples of their application.

>From a Smalltalk viewpoint ...

I think you'll have a problem finding something like this as there are no
hard and fast rules about the sort of collection type to use, there is often
no right and wrong. Each collection has it's own attributes and you have to
decide which is closest in relation to the context of the application.

Once you get to know each collection's attributes then it becomes reasonably
easy to know which situation requires which type of collection. For example,
you mentioned always using OrderedCollections rather than Bags. If the
context is a small collection then it won't matter but if you have a large
collection then lookup in a Bag is much (much) more efficient than an
OrderedCollection (assuming that an ordering of the elements is not needed).

Another difficulty with providing examples is that collection types are not
fixed. Creating an OrderedCollection, adding elements sequentially and the
converting to a SortedCollection can, depending on the context, be better
that starting with a SortedCollection.

Ian

Ted Bracht wrote:

Thanks Ted,

Amazon says it is out of print, but they act as 'go betweens' to get you a used copy.
Haggling - you are supposed to specify your price and the number of weeks they should search. What year was
it published and any ideas on original price ? Assuming you are in N.America - $US ?

Jimmy, Calgary AB

Jimmy,


"James J. Gavan" <[hidden email]> wrote in message news:<[hidden email]>...
I'm in the UK, and this (UK) bookshop say they can still supply it,
for £39.46 (around $60)

http://bookshop.blackwell.co.uk/

But even the publisher (McGraw-Hill) doesn't have it in their catalog
anymore....

Hope this helps,

Ted

>
> Jimmy, Calgary AB

Ted Bracht wrote:

Ted,

Many thanks - maybe I'll get my favourite cousin up in Carlisle to get it for me.

Jimy, Calgary AB