From: Tom Sawyer <transami@...>
Date: 2002-08-08T22:43:11+09:00
Subject: Re: Named paramters again

hi david,

On Thu, 2002-08-08 at 06:48, dblack@candle.superlink.net wrote:
> That's from a Perl 6 RFC; the same document also says:
> 
>    Hash keys are string, and Array keys are Integer
> 
> :-)
> I'm not saying there isn't anything of interest for Ruby programmers
> in looking at hashes and arrays together (if you search for "to_h
> dblack" on ruby-talk, you'll see the evidence) -- just that
> applicability of a Perl discussion to Ruby hashes is not self-evident.

yes, it is from Perl 6 RFC. but the general notion is indifferent to
language.

i'll have to check out that search! :-)

> For speed, convenience, flexibility... :-)  Unless your new type did
> *everything* that *both* arrays and hashes do (rather than just the
> intersection), it would not serve to replace either.  You'd just end
> up feeling the need for a hash/dictionary/associative array type of
> type, and have to create it.

well, i think it can do everythng they both do, although there would
probably be a few places where things will need to differ from the
current implementation of array and hash. but no loss of functionality.
you may be right about speed, but i doubt signifficantly. how much
slower is hash compared to array? of course, i certainly wouldn't
complain about having all three options.

> I don't think you can use parentheses as a constructor for a
> particular type of object -- they can go around almost anything.
> 
> In any case, the above looks to me like it could be handled easily by
> an array:

you may be right, parens might not work. not sure. be nice if they could
though. but the use of an array here, now that's punctuation heavy and
parse heavy. and is really missing the point. yes, ther is a point! ;-)

> I have to admit that the hash/array merger/elimination concept, and
> the Arguments class, strikes me as a solution in search of a problem.
> I may be wrong about that, but I don't think named parameters (if
> they're indeed a good and welcome idea) should hitch their wagon to
> it.

so, no not really, the problems are fairly evident. i imagine if i did
that serach you mentioned above i might find a few. ;-) shall see. but
right off the bat here are two: ordered hashes and named parameters.

> I guess I tend to judge named parameter syntax examples by how much
> punctuation they add to the landscape.  Yours comes in pretty high on
> that scale :-)

hmm... i don't see that, unless you consider => instead of : as too much
punctuation. in that case, you should know that of the camp that thinks
hashes should use a single marker. never liked =>. but outside of that i
don't see how it lands on the high end. you could still write code
exactly as you do now. moreover, if you take it down a level and think
about the underlying ruby implementation, the code and effiecency of the
parser would be simplified. i think that counts for a lot. so at worst,
i'd say it lands somewhere nice and squarely in the middle :-)

FYI - i think i'll give a go at this MixedContatiner class and see how
it pans. interested in the results?

by the way, david, thanks for responding.

-- 
~transami