On Wed, 2002-08-07 at 11:24, Kent Dahl wrote:
> So I'll toss out the wild & crazy idea that... *drumroll* ... 
> Named parameters can have aliases. Yep, you read that right. So that at:
> would be an alias of insertion_index:, instead of us having to
> compromise in the choice of variable names inside. And also, we could go
> a little nuts, and allow:
>   anArray.insert( "new element", at: 5 )
>   anArray.insert( "new element", at_index: 5 )
>   anArray.insert( "new element", insertion_index: 5 )

aliasing the paramters seems like a good idea. how would you implement
that?

you know i can't help but return to my earlier thoughts on this subject.
the difference between passing unnamed/ordered-arguments versus
named/unordered arguments is so very similiar to array vs. hash. so
using both "types" as method arguments is similar to what i was
attempting by making array and hash a single entity. of course for
arguments theres less to worry about, as you don't pass them around and
manipulate them. BUT that's where it gets me. why arn't arguments, being
a list of things, array-like or hash-like, not just arrays and/or hashes
to begin with?

here's an off-the-cuff notation for visual conception:

	f:[1, 2]

	f:{a=>1, b=>2}   

which is equivalent to the generally discussed:

	f(1,2)

	f(a: 1, b: 2)

now by making arguments bonified objects in themselves as either arrays
or hashes, we can do things like this:

	a = [1, 2]
	f:a

	h = {a=>1, b=>2}
	f:h

ruby currently lets us do similar things, although more limited, by
offering us terse tricks and defaults, like *a for example.

i'd be interested to hear what others might concieve of doing with this
notation, that perhaps can't readily be done with ruby currently.

now, as for bringing the two together, we get a unification of array and
hash such that we might write a "mix": (note: i use <: and :> for a lack
of unused brackets)

	m = <: 1, b=>2 :>

this mixture of array and hash necessarily combines all the
characteristics of the two, such that each parameter/element has an
index-number, a value, and optionally an index-name.

so thats my breif take on all this. the upshot being that i do think
named parameters are a good idea. but it would be nice to do it very
cleanly, with the conceptions as i have basically presented them,
although i am uncertain of exact implementation. it also indicates that,
as i have suspected, an array and a hash are not so distinct and that
they may indeed make for a more powerful entity if combined.

by seeing the equivalent nature of things and utilizing then as such, we
are blessed with a much cleaner and more powerful dialect with which to
code. but such ideas may be outside the scope of what can be improved
upon in ruby.

-- 
~transami