Hash changes to AssociativePMCArray

[allison]

Working on the aggregate PMCs section of the Parrot book, I remembered a conversation a while back that Hash should be renamed to AssociativePMCArray for consistency, and to follow Parrot's general principle of using generic terms, instead of terms from one specific HLL, at the core. Entering a ticket for it so we don't forget to do it.

This also means OrderedHash should change to OrderedAssociativePMCArray.

[whiteknight]

I think it might be a little better to just use "AssociativeArray" and "OrderedAssociativeArray" instead, as an analog for our "Array" type. Then we could subclass it to provide functionality that's specific to one of the core types if we wanted (AssociativeIntegerArray, AssociativeStringArray, etc).

[allison]

That's what I named it at first, but it seemed inconsistent with the Array series of PMCs. Names like 'ResizablePMCArray' aren't beautiful, but they have the advantage of being extremely clear. Since we already have a standard for naming Array PMCs (by behaviour and by what it stores), it makes sense to stick with it.

[coke]

What does this mean for HashIterator?

Do we need to rename that to AssociativePMCArrayIterator (And if so, does that mean we need to wait until 2.0 to do that? In which case, should we just update this ticket and do it all at once at 2.0?)

[allison]

We really shouldn't have separate Iterator classes for specific data types (though I agree the new implementation is an improvement over the old Iterator). Instead of having ArrayIterator and HashIterator as a subclass of Iterator, an Iterator should detect whether it's working with an array or hash and behave appropriately.

But, the renaming of Hash and OrderedHash shouldn't wait for this. (A note for future planning: if the keys branch had been merged after 1.4, we wouldn't have this problem of supporting experimental code.)

[bacek]

Replying to allison:

We really shouldn't have separate Iterator classes for specific data types (though I agree the new implementation is an improvement over the old Iterator). Instead of having ArrayIterator and HashIterator as a subclass of Iterator, an Iterator should detect whether it's working with an array or hash and behave appropriately.

What??? Back to Keys??? Single class to detect aggregate such as Array, Hash, OrderedHash, String and possible many other form HLL???

BTW, Current Hashes can have "native" type as values. And "native" as key except FLOATVAL. So, renaming Hash to UnorderedPMCArray is misleading.

-- Bacek

[coke]

I vote against this change.

What about 'does hash'? Should that also be spelled 'does associativearray'?

What about the internal hash type? PARROT_HASH? Hash_key_type_STRING? etc.

Perl isn't the only language to refer to this type of container as a hash, so this can't be that confusing. Is there a particular user group / language that requested this change, or was this just trying to avoid trouble down the road?

I could see adding more user-friendly documentation to explain what a hash is, but not changing a huge portion of our repository and the languages built on top of parrot to date.

[bacek]

+1 to Coke.

And Hash supports all native types as values and STRING/INTVAL/PMC as keys. So "PMC" infix is totally misleading.

-- Bacek

[coke]

Rejecting ticket. Too much lift for too little return.

Discussed in #ps today:  http://irclog.perlgeek.de/parrotsketch/2010-02-02#i_1952310