Re: Get the real object in a Hash key

On 15.04.2011 19:39, Kevin Mahler wrote:
> Robert K. wrote in post #993026:
>> I did not argue against complex keys.  The issue is with *mutable*
>> keys.  And since adding data to the key object is also associating
>> (which is done with the value as well) the most natural way would be
>> to place that additional information there.  Not to mention the
>> questionable approach to stuff something into what is usually
>> considered a simple value (String).
>
> You said "And you don't want to do it." In fact doing it has its uses.

Please do not quote out of context: that was referring to the example 
with a String instance used as a Hash key and stuffed with additional 
instance variables.

> Mutable keys or not is totally irrelevant, especially when the data
> was there before the hash was introduced, as in the original example.

The topic of key mutability is especially relevant for keys stored in a 
Hash.  Of course mutations before storing are irrelevant.  But if you 
change fields of an object which are part of the key (i.e. included in 
#hash and #eql?) you need to rehash in order for the Hash to do lookups 
properly.

Basically you can have two types of fields in an object used as a Hash key:

1. key properties (used in #hash and #eql?)

2. non key properties (neither used in #hash nor #eql?)

Type 1 properties need of course be part of the key and of course you 
need to know them to make any lookups.

Type 2 properties are irrelevant for lookups you can merely consider 
them being "associated with the key".  This leads to a situation where 
you have one instance (per key) with the associated data and potentially 
many other instances which might or might not have these properties.  If 
they are actually defined to be properties (either through attr_accessor 
or manually) you end up carrying around baggage which is not used most 
of the time.

Type 2 properties should rather go into another instance which should be 
stored as value.  This also makes it much clearer what's going on. 
Splitting up associated data into properties of key objects and an 
instance stored in the Hash doesn't really make sense.  Then we could as 
well store everything in the key instance and don't need the Hash at all.

> *Of course* making repeated calls to Hash#assoc in order to update
> stuff in the key would be stupid. That goes without saying. What would
> the purpose of the hash be? If that was your only point then we agree,
> although it was a vacuous point.

Why is the point vacuous?  Apparently OP has / had some questions about 
these topics and what may look obvious to you might not to others.

> Also do you realize that an example tends to stand for something which
> is not literally the example itself? He has a key. It contains some
> data. It's not necessarily true that he should duplicate that data in
> the mapped-to values. Mutable or not is beside the point.

Well, but we cannot read other people's minds.  We have to take the 
example at face value.  Stuffing additional data into a String is not a 
good idea and I am not sure whether that occurred to OP or not.  So this 
might really be what he is attempting.  In this case "stuffing the data 
into the key" was part of the example and it was nowhere expressed that 
this is a fact that could not be changed.

And btw, I did not recommend to duplicate that data in the mapped-to 
value.  I specifically suggested to place it there exclusively.

> I notice this phenomenon a lot: undergeneralization. The String stands
> for something. It's his key data. If it were a simple value then the
> example wouldn't make sense in the first place. Gee, thanks for
> telling us that we shouldn't stuff random shit into a simple value and
> then use that as a hash key, whereupon we can't look up stuff in the
> hash directly but must use Hash#assoc instead. Again, if that was your
> point then we agree, albeit in the obvious and nearly information-free
> sense. I'm sure we would also agree that cats would be a poor building
> material for helicopters.

As is rudeness for a community.

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/