On Dec 18, 7:49 pm, Phrogz <phr... / mac.com> wrote:
> On Dec 18, 6:29 pm, Trans <transf... / gmail.com> wrote:
>
>
>
> > On Dec 18, 7:05 pm, Phrogz <phr... / mac.com> wrote:
>
> > > I wanted a method like Hash#update, but that preserved the values from
> > > both the original and argument Hash. A little searching failed to find
> > > it. (I did find that someone somewhere wrote a Hash#collate that's in
> > > my ri docs, but who knows where it came from. Its description appears
> > > not to do at all what I wanted, anyhow.)
>
> > That's from Facets, probably. But the latest version of Facets renamed
> > it to #mash, for "map hash", which is more descriptive of what it
> > does. (#collate remains an alias for the time being).
>
> > I like your definition --actually I'm surprised I haven't worked this
> > functionality into Facets yet. I guess I thought #weave took care of
> > it, but that's slightly different b/c it only combines arrays if the
> > value is already an array. So I'm going to add this to Facets. A
> > couple thoughts though...
>
> > The options don't feel quite right. Maybe it would more versatile to
> > define #uniq on Hash? So then
>
> >   { :a=>1, :b=>2 }.collate( { :a=>1, :b=>3 } ).uniq
> >   #=> { :a=>[1], :b=>[2,3] }
>
> That's an excellent point. I needed this functionality today and so I
> included it in the script; however, since it's a simple one-line (as
> seen in the implementation) post-process step, perhaps it's
> appropriate to keep it out of this method.
>
> > As for preserving the arrays, I'm not sure. Is that really all that
> > useful? Well, if it is it seems like a better definition for Hash#zip.
>
> The reason I made the arrays not be preserved by default is to enable
> chained collation of 3 or more hashes. (test5_multicollate in the unit
> tests.) I was actually collating hundreds today. However, I put in the
> 'preserve arrays' because it seemed almost arbitrary to treat them
> differently from every other type of value. I don't personally have a
> use case that needs it now, but I know from experience (like #flatten
> versus #flatten_once) how sometimes arrays of arrays can suddenly crop
> up and need to be preserved.
>
> I would dearly love to get rid of the options hash altogether,
> though. :)

One alternative would be to drop the idea of preserving collation
order altogether, and instead accumulate the results as a Set.
Although the method would still need to branch on value type (since
set1 << set2 isn't the same as set1.merge set2), it seems far less
likely that someone would have a Hash whose values were Sets and
wanted to maintain each set as a distinct 'value' during collation.