[RCR] introducing Hash-like mixin

[gabriele renzi]

Hi gurus and nubys,

If you ever wanted to subclass hash but it was too hard..

If you ever wanted to write Hash::Regexp, Hash::Approx and
Hash::Cannabinol in ruby, but felt that you have to implement too much
methods..

in general if you ever used YourClass#[]=(key,val)..

go vote for this rcr

Ok, stop cheerleading, the rcr is here:
http://rcrchive.net/rcr/RCR/RCR261

A better name than Hashable (inexact) and Map (misses the -able
prefix) would be much appreciated.

 

[Martin DeMello]

A better name than Hashable (inexact) and Map (misses the -able
prefix) would be much appreciated.

Indexable?

martin

 

[Ara.T.Howard]

Indexable?

martin

Array.

-a
--
===============================================================================
| EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
| PHONE :: 303.497.6469
| A flower falls, even though we love it; and a weed grows, even though we do
| not love it. --Dogen
===============================================================================

 

[Ara.T.Howard]

Hi gurus and nubys,

If you ever wanted to subclass hash but it was too hard..

If you ever wanted to write Hash::Regexp, Hash::Approx and
Hash::Cannabinol in ruby, but felt that you have to implement too much
methods..

in general if you ever used YourClass#[]=(key,val)..

go vote for this rcr

Ok, stop cheerleading, the rcr is here:
http://rcrchive.net/rcr/RCR/RCR261

A better name than Hashable (inexact) and Map (misses the -able
prefix) would be much appreciated.

HashEnabled?

-a
--
===============================================================================
| EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
| PHONE :: 303.497.6469
| A flower falls, even though we love it; and a weed grows, even though we do
| not love it. --Dogen
===============================================================================

 

[gabriele renzi]

HashEnabled?

the point is that a Map(temporary name) object can look like ruby's
Hashes, but have a much different implementation (say, some kind of
tree), and hashing defines a specific behaviour. Dictionary may be
another one, but still ugly to me.

 

[Gavin Sinclair]

il Thu, 17 Jun 2004 06:27:25 -0600, "Ara.T.Howard" <[email protected]>
ha scritto::

the point is that a Map(temporary name) object can look like ruby's
Hashes, but have a much different implementation (say, some kind of
tree), and hashing defines a specific behaviour. Dictionary may be
another one, but still ugly to me.

Map or Dictionary are the only real choices, AFAIC. I really like Map
as a name here.

Gavin

 

[Michael Neumann]

Map or Dictionary are the only real choices, AFAIC. I really like Map
as a name here.

Instead of the suffix -able (as in Enumerable), a -Mixin suffix is another
choice, e.g. MapMixin or HashMixin.

Regards,

Michael

 

[Ara.T.Howard]

the point is that a Map(temporary name) object can look like ruby's
Hashes, but have a much different implementation (say, some kind of
tree), and hashing defines a specific behaviour. Dictionary may be
another one, but still ugly to me.

well, what are the 'requirements'? O(1) lookup, insertion and deletion? key
-> value lookup? etc. if it's mapping keys to values, then that could be
called mapping or hashing i suppose. what about something involving 'key' and
'value'? or something using indexable with a refinement for things indexable
by number, or by any object? map may be the best work to describe this
behaviour...

-a
--
===============================================================================
| EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
| PHONE :: 303.497.6469
| A flower falls, even though we love it; and a weed grows, even though we do
| not love it. --Dogen
===============================================================================

 

[Bill Kelly]

the point is that a Map(temporary name) object can look like ruby's
Hashes, but have a much different implementation (say, some kind of
tree), and hashing defines a specific behaviour. Dictionary may be
another one, but still ugly to me.

PairAssociative?

Borrowed from my C++ STL book[1], which lists hash_map<> as a
model of Pair Associative Container (as well as a model of
Hashed Associative Container and Unique Associative Container).


Regards,

Bill

[1] Generic Programming and the STL, Austern, Matthew H.

 

[Mark Hubbart]

the point is that a Map(temporary name) object can look like ruby's
Hashes, but have a much different implementation (say, some kind of
tree), and hashing defines a specific behaviour. Dictionary may be
another one, but still ugly to me.

PairAssociative?

Borrowed from my C++ STL book[1], which lists hash_map<> as a
model of Pair Associative Container (as well as a model of
Hashed Associative Container and Unique Associative Container).

PairAssociable? Associable?

cheers,
Mark

 

[Josh Huber]

PairAssociable? Associable?

Hmm, it sounds odd to me, but it has the right definition:

associable
adj : capable of being associated; "words associable with
politics"

I guess I don't hear "associable" too often...

 

[Dave Burt]

Hmm, it sounds odd to me, but it has the right definition:

associable
adj : capable of being associated; "words associable with
politics"

I guess I don't hear "associable" too often...

No, it's not right - the container itself is an associator; it associates
its key/value pairs, which are associable.

I recommend Associative

 

[Jim Weirich]

Instead of the suffix -able (as in Enumerable), a -Mixin suffix is another
choice, e.g. MapMixin or HashMixin.

Or MapMethods and/or HashMethods.

It reads nicely ...

class Dictionary
include MapMethods
....
end

 

[Gavin Sinclair]

Hmm, it sounds odd to me, but it has the right definition:

associable
adj : capable of being associated; "words associable with
politics"

I guess I don't hear "associable" too often...

s = FooBar.new
t = Quux.new

h = {}
h = t

s and t are now associated with other. Are s and t Associable?

Gavin

 

[gabriele renzi @ google]

well, what are the 'requirements'? O(1) lookup, insertion and deletion? key
-> value lookup? etc. if it's mapping keys to values, then that could be
called mapping or hashing i suppose.

from the rcr: "provide a mixin for key->value mappings"
Sorry for not have stated this more clearly, but this mixin, in my
'vision', would be going to work with any kind key->value mappers, say
dbm/sdbm/gdbm/pstore/rbtree, and even stuff like Dict servers, LDAP
directories, or wikipedia.

The point that classes may be using some kind of hashing internally is
just an implementation detail. But, as I said, it's my fault to have
written such a misleading title. It was hard to fill all that blank
fields in the rcr page.

what about something involving 'key' and
'value'? or something using indexable with a refinement for things indexable
by number, or by any object? map may be the best work to describe this
behaviour...

Interesting, I like the idea of micro interfaces/mixin and fine
grained refinements, but it's up to matz to decide.
<plug>
And, btw, if somebody like this, please take two minutes to vote at
rcrchive.net
</plug>

 

[Sascha Doerdelmann]

Borrowed from my C++ STL book[1], which lists hash_map<> as a
model of Pair Associative Container (as well as a model of
Hashed Associative Container and Unique Associative Container).

Boost (a collection of C++ template libraries) works with tupels
rather than with pairs.

In Smalltalk there is a Collection class named KeyedCollection but
Array is an ArrayedCollection, the latter a subclass of
SequenceableCollection. Dictionary is a Subclass of Set.
IdentityDictionary is not a subclass of Dictionary. I don't want to
discuss Smalltalk's single inheritance. I just want to point out that
there are a lot of koncepts to take into account.

- fixed order (sorted keys) vs.
variable order (may change sort function) vs.
no order (hashed keys)
- fixed type keys vs.
arbitrary but constant type vs.
mixable types
- access by keys in constant time?
- allow dublicated values?
- how to cope with equal but not identical keys?
- fixed size or growable?

This list is not complete, I just did some brainstorming.

I think an appropriate name will come up when decision about the
interface is complete.

Cheers
Sascha

 

[Michael Neumann]

Or MapMethods and/or HashMethods.

It reads nicely ...

class Dictionary
include MapMethods
....
end

Yes, I like it. That sound much more natural and tells what's actually
doing (including methods related to mapping).


Regards,

Michael