@Alan

I'm trying to understand why you find the solution you gave "gross"

> I could construct all the objects and have a single "global" map, with
> mappings for both set-id=>[objects] and object=>set-id, but this seems
> kinda gross and obscures what is actually meant (objects belong to
> sets) with implementation (integers/keywords mapping to groups of
> objects, and objects mapping to integers).

But you say:

> In an imperative language this would be fairly simple: create some
> empty sets, then iterate over all objects; at each step add the object
> to a set, and adjust the object's "parent" pointer to point at the set
> it's in.

Aren't these two same?

add object to a set _v/s_ set-id => #{objects}
adjust the object's "parent" pointer _v/s_ object => set-id

Only differences for me are:
1. In the imperative case you don't have to create a 'set-id'.  But
'set-id' would naturally come from the way you're partitioning in the
first place.
2. In the functional case you don't have to create a parent pointer
inside the object (which looks ugly to me - what is object's business
to know where it is lying? Tomorrow if you put the object in a second
set, will you add a parent2 or create a parents array or perhaps a map
of parent-id to parent itself).

Note that I may be totally misplaced or missing several things - just
trying to understand.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Reply via email to