{
1 => 2,
2 => 3,
3 => 4,
|x|
x + 1
}
This is essentially a hash with a default_proc that adds 1 to its argument.
Leave out the => pairs and you get something that acts like a proc.
Leave out the |...|... construct and you get something that acts like a
hash. With both, it's a hash with a default proc.
It's backwards compatible.
Are there any syntactic ambiguities?
It's a fllor wax AND a dessert topping!
> It's backwards compatible.
Delicious! And just look at that shine!
> Are there any syntactic ambiguities?
Hmm, not sure. But it certainly gives me a headache to think about it.
Hal
Witty! What's somewhat dubious in it is melting two things which are so
different as objects. A hash is basicly transparent, a proc is basicly
opaque. And an object which has a proc as an attribute in some sense
won't just become a proc...
But, hm, all-in-all, I like it. I always tend to think of hashes as
mappings defined at finitely many places, abstracting from the data
structure which implements it (and gives it its name).
Csaba
Enumerable does serve the purpose of defining a common abstract interface
already. Note also, that lists are usually ordered and their elements
don't change positions unless explicit told to. This is not true for a
Hash - at least not as it's implemented right now. Personally I dislike
changing Hash to add the overhead of remembering insertion order as this
is likely to slow down Hash typical operations.
The other problem with a common superclass / mixin of Array and Hash is,
that sometimes you want them treated similar (i.e. both have [] and []=
and can be accessed indexed; you can view an Array as a specialized Hash
that allows only Fixnum keys) and sometimes you don't. I still haven't
seen something that would consolidate this better than Enumerable does.
> This is more along the path that Perl took, where hashes and arrays are
> both lists. Then the {} would then be free, FREE, to be used for
> whatever nefarious purposes we could devise.
The sole fact that you mention perl here makes the whole proposal
suspicious to me. :-) I'd rather find a ruby solution than to look at
other languages.
> Not being a language designer, I have no idea if this is better or
> worse, if the List superclass is really necessary (i.e. could we still
> use a mixin strategy?), or if it would even be possible to implement in
> Ruby 2.0.
Personally I don't think we really need this change. Just my 0.02EUR...
Kind regards
robert
If Ruby had a "List" superclass from which Array and Hash descended,
instead of the Enumerable mixin strategy, this would have been easier I
think. Presumably (and I'm totally guessing here) a list would have
been anything between square brackets:
[1,2,3,4].kind_of?(List) # true
[1,2,3,4].kind_of?(Array) # true
[1,2,3,4].kind_of?(Hash) # false
[1 => 2, 3 => 4].kind_of?(List) # true
[1 => 2, 3 => 4].kind_of?(Hash) # true
[1 => 2, 3 => 4].kind_of?(Array) # false
(I believe someone else proposed this syntax earlier.)
This is more along the path that Perl took, where hashes and arrays are
both lists. Then the {} would then be free, FREE, to be used for
whatever nefarious purposes we could devise.
Not being a language designer, I have no idea if this is better or
worse, if the List superclass is really necessary (i.e. could we still
use a mixin strategy?), or if it would even be possible to implement in
Ruby 2.0.
Who knows? Maybe I'll learn to design a language someday and give this
a shot to see how it pans out. :)
Regards,
Dan