Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   Ruby (http://www.velocityreviews.com/forums/f66-ruby.html)
-   -   Yield & associations (was Proc / def /yield semantics) (http://www.velocityreviews.com/forums/t816933-yield-and-associations-was-proc-def-yield-semantics.html)

Markus 09-27-2004 12:03 AM

Yield & associations (was Proc / def /yield semantics)
 
On Sun, 2004-09-26 at 15:11, Mark Hubbart wrote:
> On Sep 26, 2004, at 11:54 AM, Markus wrote:
>
> > 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






















Mark Hubbart 09-27-2004 07:04 PM

Re: Yield & associations (was Proc / def /yield semantics)
 

On Sep 26, 2004, at 5:03 PM, Markus wrote:

> On Sun, 2004-09-26 at 15:11, Mark Hubbart wrote:
>> On Sep 26, 2004, at 11:54 AM, Markus wrote:
>>
>>> 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?


IIRC, Values is the encapsulation class for parameter lists and
multiple assignment lists. I could easily be wrong, but I think that in
the future when you use the splat operator to collect items, you will
end up getting a Values object, not an Array. I think.

cheers,
Mark
>
> -- Markus






All times are GMT. The time now is 02:35 AM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.