Question about model, collection class choice

Hi everyone,

I have a bunch of objects (all instances of the same class) which each hold a Date.  There is another singleton-style class which holds a Dictionary to keep track of those objects, where the key is the Date and the value is the object.

How bad is it that I am keeping the date once in the object, and again as the key in the Dictionary?  Would it be better to only have the Date stored once, in the object, and then collect them some other way?  Say a Set, or an OrderedCollection?  Or is something smart going on, where the Date actually only exists once, and the key is internally some hash value, so my worry is misplaced?

I like the readability and consistency of Dictionary>>at: aDate returning the object I want.  With an OrderedCollection or indexed variables or something it seems like the code would be less elegant, with maybe a lot of #select: and #collect: thrown in.  

I cannot collect these objects solely though #allInstances because I use the SMFileDatabase persistency mechanism which requires a root object to store.  I think I could use a class variable (or class instance variable?) for keeping track of the objects, in place of the singleton class, but I am fuzzy on that.

Any wisdom would be appreciated!

Thanks,
Tim

_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

On Wed, May 4, 2011 at 10:27 AM, Tim Johnson <[hidden email]> wrote:
> Hi everyone,
>
> I have a bunch of objects (all instances of the same class) which each hold a Date.  There is another singleton-style class which holds a Dictionary to keep track of those objects, where the key is the Date and the value is the object.

This is probably the most common way to do it.   #allInstances is
great for debugging, but I don't like using it for applications.

> Or is something smart going on, where the Date actually only exists once, and the key is internally some hash value, so my worry is misplaced?

This is not the way I would say it, but I think this is what is going
on.   Each Date can be referenced from many places.   The exact same
object is both the value of your object's date field, and also the key
in the dictionary.  Dates are not copied unless you explicitly copy
them.   Assignment is not copying in Smalltalk.

-Ralph Johnson
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

On Wed, 4 May 2011, Tim Johnson wrote:

> Hi everyone,
>
> I have a bunch of objects (all instances of the same class) which each hold a Date.  There is another singleton-style class which holds a Dictionary to keep track of those objects, where the key is the Date and the value is the object.
>
> How bad is it that I am keeping the date once in the object, and again as the key in the Dictionary?  Would it be better to only have the Date stored once, in the object, and then collect them some other way?  Say a Set, or an OrderedCollection?  Or is something smart going on, where the Date actually only exists once, and the key is internally some hash value, so my worry is misplaced?

If you don't copy the Date object, then the instance's Date object is used
for the key.

There's a special data structure, that does exactly what you did:
KeyedSet. It's a Sst of objects, but it also has a dictionary-like
interface. The lookup key is calculated from the object's data using a
block. Something like this should work:

collection := KeyedSet keyBlock: [ :object | object date ].

Using a KeyedSet will let you simplify your code a bit, e.g. you can use
#add: to add your objects instead of #at:put:

>
> I like the readability and consistency of Dictionary>>at: aDate returning the object I want.  With an OrderedCollection or indexed variables or something it seems like the code would be less elegant, with maybe a lot of #select: and #collect: thrown in.
>
> I cannot collect these objects solely though #allInstances because I use the SMFileDatabase persistency mechanism which requires a root object to store.  I think I could use a class variable (or class instance variable?) for keeping track of the objects, in place of the singleton class, but I am fuzzy on that.

There's no need to sacrifice simplicity, readability and performance by
using OrderedCollection or #allInstances.


Levente
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners