> Perhaps. I keep feeling that there is an "Ah ha!" lurking in
> here somewhere--if we just look at things on the right way, we could
> (for 2.0) get nearly full backward compatibility, cleaner semantics,
> and nice route for expanded expressiveness. I'll post more if the
> idea still seems reasonable after I think on it for a day or so...If Association is a subclass of Array or Values, then it should be
possible to splat it. Here's an extremely bare-bones version
demonstrating the possible behavior:
This looks to be very much along the lines I have been thinking,
except that I am totally ignorant of the class Values. Can you give me
a little background?
It's a neat idea, but I would wonder how practical it would be; I get
the feeling our nice fast hash lookups would be ruined... But since I
don't know the internals...
I'm thinking it could be done in a way that was almost pure sugar.
The key would be finding a way to decompose the current syntax into
cogent chunks that, when combined in the usual ways would have the usual
meanings, but could also be meaningfully combined in _new_ ways.
For example (WARNING: this should be a 2.0-at-the-earliest change
and in any case I'm still in the process of thinking it out):
* Define a class Association < Array with the methods key & value
(perhaps as synonyms for first and last), and Association#hash
returns self.key.hash.
* Open up the set of user-definable operators to include anything
that matches /[+-*/=<>.&^%!~]+/ or what have you.
* Make Object#=>(other) return Association.new(self,other)
* Make a hash work on anything that responds to "hash" (in other
words, anything) by storing the object under its hash.
* Make { v1,v2,v3...} build a hash, analogous to the way in which
[ v1,v2,v3...] builds an array. Note:
* This doesn't depend on the v's being constructed by =>,
but if they are the semantics would be the same as
always.
* The semantics of { k1,v1, k2,v2, k3,v3,... } would
change; it would produce something more like a set, with
the k's & v's as elements.
* The semantics of [ k1=>v1, k2=>v2...] would change;
instead of producing an array containing a single hash,
it would produce an (ordered) array of associations.
* The semantics of implicit hash arguments might change
* The semantics of Hash#to_a perhaps ought to be changed
* Let people implement their own functionality with these building
blocks (e.g., all the flavours of "ordered" hashes discussed a
few weeks ago should be trivial).
* Deprecate some of the functions that have been added to array to
support sets, associations, etc. and could now be better
implemented with these tools.
I'd call this a taste of my grand vision if I was more convinced
that it wasn't a whiff of my temporary hallucination. I'm in the
process of trying to puzzle out: 1) what does it break, 2) what would
break it (e.g. cause it to exhibit counter-intuitive behavior), and 3)
could it in fact be implemented.
Any thought/comments/questions/criticisms are welcome.
-- Markus
···
On Sun, 2004-09-26 at 15:11, Mark Hubbart wrote:
On Sep 26, 2004, at 11:54 AM, Markus wrote: