From: itsme213 <itsme213@...>
Date: 2005-01-06T11:11:31+09:00
Subject: Re: Seeking info on keyword parameters

"itsme213" <itsme213@hotmail.com> wrote

>     x.send :move args
>         becomes
>     x.send default_ns::move args
>         or, as an alternative language design choice
>     x.send current_ns::move args

If the selector had keyword arguments
    def move(from:, to:) ... end
then I believe the send version could be:
    x.send( :move, from: f, to: t ) # (current thinking; :move:from:to is a
different approach)

To dynamically build a send, we must have reflective access to keyword
argument names.

So: it is necessary that:
    x.methods
returns things that understand keywords e.g. method data objects
    [ method_data1, method_data2, ... ]
where
class MethodData
    attr_accessor :selector_symbol, :keywords
end
class SelectorSymbol < Symbol
    attr_reader :namespace
end

Similarly, #public_methods, #instance_methods, etc. should all return
method_data with selector symbols + keyword arg information. Similarly, the
return value of def.

And, since it makes sense for all method signature information to be
together, we could also let MethodData carry information about arity, and
block arguments wherever these are appropriate e.g. in the retutn values of
def, #methods, #public_methods, #instance_methods.

Methods that lookup methods given SelectorSymbols (e.g.
#instance_method(selector), #method(selector), #send, #method_missing) have
to be namespace aware (which they get via SelectorSymbol). They will only
need keywords and arity information if we allow things like overloading..

In summary I think the following are closely related to selector namespaces:
- selector symbols that know about namespaces
- selector symbol indexing of methods (not string or symbol index)
- some kind of MethodData object that combines selectors with keywords,
arity, etc.

And the following are closely related to keyword args:
- MethodData objects
- composite selectors like :move:from:to
- keyword parameters for #send and x.foo invocations
- reflective access to keyword parameter names
- #methods, #instance_methods, #method(s), etc. handling keyword parameter
names
- whether or not keyword args must be provided in fixed order
- overloading of keyword argument methods

I like the idea of composite selectors like :move:from:to, but the keyword
order becomes encoded in the selector symbol. While I personally would not
mind if keyword arguments in a call had to be in the same order as declared
in a method, it is not as good a fit with Ruby's defaul parameter values and
allowed re-ordering of keyword arguments.