Seeking info on keyword parameters

ruby-talk
1

Will 2.0 make the names of keyword parameters available via reflection?

Sorry to ask this again, but it is really important for me. I decided years
ago that I much prefer

1) helper.move desk from: kitchen to: study using: trolley before: tomorrow
  to
2) helper.move_from_to_using_before(desk, kitchen, study, trolley, tomorrow)
   which is arguably somewhat better than
3) helper.move(desk, kitchen, study, trolley, tomorrow)

So I am very concerned about keyword parameter names being available to
reflection.

Separately but related: will keyword parameter names be treated as part of
the method names for method lookup, allowing a form of overloading?

Could anyone shed some light on the plans here? Thanks.

2

Hi,

···

In message "Re: Seeking info on keyword parameters" on Tue, 4 Jan 2005 19:16:33 +0900, "itsme213" <itsme213@hotmail.com> writes:

Will 2.0 make the names of keyword parameters available via reflection?

Unlike your expectation, 2.0 keyword arguments will look like
Python's. They are like "named optional arguments", rather than
Smalltalk style method names.

              matz.

3

Yukihiro Matsumoto ha scritto:

Hi,

>Will 2.0 make the names of keyword parameters available via reflection?

Unlike your expectation, 2.0 keyword arguments will look like
Python's. They are like "named optional arguments", rather than
Smalltalk style method names.

              matz.

maybe I'm reading too much in this message, but did you left the idea of having separated named arguments and default arguments ?

···

In message "Re: Seeking info on keyword parameters" > on Tue, 4 Jan 2005 19:16:33 +0900, "itsme213" <itsme213@hotmail.com> writes:

4

Yukihiro Matsumoto wrote:

Hi,

Moin.

>Will 2.0 make the names of keyword parameters available via reflection?

Unlike your expectation, 2.0 keyword arguments will look like
Python's. They are like "named optional arguments", rather than
Smalltalk style method names.

Still, could we not add a method to Method objects that gives us more information about the method signature then just how many arguments it expects? I think it would be nice if we could somehow get the names of keyword and regular arguments and the default value. Maybe an Array of [symbol, type, default] where type would be something like :regular, :keyword, :grab, :block_grab, :keyword_grab or nil and default and symbol nil if not appropriate. While we are at it we could also add Method#mandatory_argc.

I think that information could be extracted from the Node tree on-demand so it would not have an overhead unless it is really used.

Does this sound possible? Would it be worth the effort?

···

In message "Re: Seeking info on keyword parameters" > on Tue, 4 Jan 2005 19:16:33 +0900, "itsme213" <itsme213@hotmail.com> writes:

5

Hi,

···

In message "Re: Seeking info on keyword parameters" on Tue, 4 Jan 2005 20:16:34 +0900, gabriele renzi <rff_rff@remove-yahoo.it> writes:

maybe I'm reading too much in this message, but did you left the idea of
having separated named arguments and default arguments ?

I assume you are suggesting Smalltalk style

  foo.move a from: b to: c

method invocation which mentioned by itsme. I'm not positive that it
fits in Ruby. How can I specify such a method by a symbol, for
example?

              matz.

6

"Florian Gross" <flgr@ccan.de> wrote in message
news:33vd54F45vujfU1@individual.net...

Yukihiro Matsumoto wrote:
> Unlike your expectation, 2.0 keyword arguments will look like
> Python's. They are like "named optional arguments", rather than
> Smalltalk style method names.

Thanks for the clarification regarding overloading, Matz. I can live with
this.

I'm not sure I got the answer to my first question: will the names be
available via reflection.

Still, could we not add a method to Method objects

This is where I get a bit lost. This information belongs with UnboundMethod
objects, doesn't it? It would be fine to have indirect access to it via
Method objects.

that gives us more
information about the method signature then just how many arguments it
expects? I think it would be nice if we could somehow get the names of
keyword and regular arguments and the default value. Maybe an Array of
[symbol, type, default] where type would be something like :regular,
:keyword, :grab, :block_grab, :keyword_grab or nil and default and
symbol nil if not appropriate. While we are at it we could also add
Method#mandatory_argc.

I think that information could be extracted from the Node tree on-demand
so it would not have an overhead unless it is really used.

Does this sound possible? Would it be worth the effort?

I would very much like what Florian proposes. Could it please be made
extensible so someone could add on other method and parameter meta-data they
found useful?

7

Yukihiro Matsumoto ha scritto:

Hi,

>maybe I'm reading too much in this message, but did you left the idea of >having separated named arguments and default arguments ?

I assume you are suggesting Smalltalk style

  foo.move a from: b to: c

method invocation which mentioned by itsme. I'm not positive that it
fits in Ruby. How can I specify such a method by a symbol, for
example?

              matz.

sorry for being unclear.
I meant if you still think that arguments declared with "=" are separated from argument declared with ":", :

def foo(a=10, b: 20)... end
foo(7, b: 40)

since you wrote "look like python" I hoped that you changed your mind by allowing 'named' passing for all arguments:

def foo(a=10, b=20)
foo b: 40, a: 20

···

In message "Re: Seeking info on keyword parameters" > on Tue, 4 Jan 2005 20:16:34 +0900, gabriele renzi <rff_rff@remove-yahoo.it> writes:

8

itsme213 wrote:

Still, could we not add a method to Method objects

This is where I get a bit lost. This information belongs with UnboundMethod
objects, doesn't it? It would be fine to have indirect access to it via
Method objects.

Well, I was talking about Methods in general e.g. both bound methods and unbound methods. Currently the naming of the classes is a bit confusing.

I would very much like what Florian proposes. Could it please be made
extensible so someone could add on other method and parameter meta-data they
found useful?

I don't think there's more meta-data than the above.

9

Yukihiro Matsumoto schrieb:

I assume you are suggesting Smalltalk style

  foo.move a from: b to: c

method invocation which mentioned by itsme. I'm not positive that it
fits in Ruby. How can I specify such a method by a symbol, for
example?

I think in Objective-C and Smalltalk the method name would be "move:from:to:". So in Ruby the Symbol would be :"move:from:to:".

Regards,
Pit

10

"Florian Gross" <flgr@ccan.de> wrote in message
news:33vgveF4358soU1@individual.net...

> I would very much like what Florian proposes. Could it please be made
> extensible so someone could add on other method and parameter meta-data

they

> found useful?

I don't think there's more meta-data than the above.

Not built into Ruby, true. But an app might have its own meta-data, possibly
domain-specific. Perhaps things like param types, or data about how
parameters are interpreted by a method (e.g. "either a list of dates, or a
start date and a list of durations "), etc. A domain-specific Ruby could add
Class#methods to declare such things.

11

Hi,

···

In message "Re: Seeking info on keyword parameters" on Tue, 4 Jan 2005 21:01:34 +0900, gabriele renzi <rff_rff@remove-yahoo.it> writes:

I meant if you still think that arguments declared with "=" are
separated from argument declared with ":", :

Ah, they will be separated (unlike Python).

              matz.

12

"Pit Capitain" <pit@capitain.de> wrote in message
news:41DB0D2C.8010103@capitain.de...

Yukihiro Matsumoto schrieb:
> I assume you are suggesting Smalltalk style
>
> foo.move a from: b to: c
>
> method invocation which mentioned by itsme. I'm not positive that it
> fits in Ruby. How can I specify such a method by a symbol, for
> example?

I think in Objective-C and Smalltalk the method name would be

"move:from:to:".

So in Ruby the Symbol would be :"move:from:to:".

Seems like that would work. Also seems loosely consistent with the new {foo:
x, bar: y} syntax for symbol keys.

Will keyword invocation syntax permit leaving out the parenthesis? i.e.
    foo.move( a, from: b, to: c)
as well as
    foo.move a, from: b, to: c
?

If a subclass of Symbol like SelectorSymbol also had a @namespace slot to
provide selector namespaces (which would be great with Ruby's modules and
re-opening of classes; SmallScript does something similar), we would also
need some way to associate a namespace with a selector symbol. e.g.
    x.send :move # which namespace? symbol or selector symbol?
    x.send N1::move # ah, N1's :move selector symbol
    x.send :move # send could treat :move symbol as default_ns::move
selector symbol?

13

itsme213 wrote:

other method and parameter meta-data

I don't think there's more meta-data than the above.

Not built into Ruby, true. But an app might have its own meta-data, possibly
domain-specific. Perhaps things like param types, or data about how
parameters are interpreted by a method (e.g. "either a list of dates, or a
start date and a list of durations "), etc. A domain-specific Ruby could add
Class#methods to declare such things.

I think that's outside the scope of the above request.

That aside I think custom meta-data should be implemented via custom methods on method objects. This would be easier if method objects were to be cached by Ruby.

14

Yukihiro Matsumoto ha scritto:

Hi,

>I meant if you still think that arguments declared with "=" are >separated from argument declared with ":", :

Ah, they will be separated (unlike Python).

              matz.

ah, thanks for clarifying :slight_smile:

···

In message "Re: Seeking info on keyword parameters" > on Tue, 4 Jan 2005 21:01:34 +0900, gabriele renzi <rff_rff@remove-yahoo.it> writes:

15

Hi,

Will keyword invocation syntax permit leaving out the parenthesis? i.e.
   foo.move( a, from: b, to: c)
as well as
   foo.move a, from: b, to: c
?

Yes.

If a subclass of Symbol like SelectorSymbol also had a @namespace slot to
provide selector namespaces (which would be great with Ruby's modules and
re-opening of classes; SmallScript does something similar), we would also
need some way to associate a namespace with a selector symbol. e.g.
   x.send :move # which namespace? symbol or selector symbol?
   x.send N1::move # ah, N1's :move selector symbol
   x.send :move # send could treat :move symbol as default_ns::move
selector symbol?

I'm not sure I get you, but I feel like you're suggesting something
interesting. Let me consider. Detailed explanation would be welcomed.

              matz.

···

In message "Re: Seeking info on keyword parameters" on Wed, 5 Jan 2005 12:36:33 +0900, "itsme213" <itsme213@hotmail.com> writes:

16

itsme213 wrote:

Not built into Ruby, true. But an app might have its own meta-data, possibly
domain-specific. Perhaps things like param types, or data about how
parameters are interpreted by a method (e.g. "either a list of dates, or a
start date and a list of durations "), etc. A domain-specific Ruby could add
Class#methods to declare such things.

This naturally makes me think of:

def read_dat_file(filename):
   """Read Code Composer data file

   File format: ASCII, optional header line followed by data, one word per line

   filename -- name of dat file to read

   Returns list of data values.
   """
   f = open(filename, 'r')
   lines = f.readlines()
   f.close()

   ...

AKA Python's docstring inside a function.

I think it would be *amazing* if a docstring like that were available in Ruby, and if it were available via reflection. It could be used in all kinds of ways: from within IRB sessions, as part of error messages, as a "service discovery" kind of tool...

I also really like the idea of some kind of MethodData or MethodDescriptor objects that can describe themselves, list their keyword args, list the default values, etc.

And while we're at it, I don't see a good reason why every arg shouldn't automatically be a keyword arg. Sure, sometimes you really don't need one, like "sqrt(foo)", it's pretty obvious that "foo" must be the number you want to find the square root of, but would it hurt to be able to say sqrt(num: foo)? The only downside I can see, from a user's point of view, is that not all methods may expose sensible names, so the keywords may not make sense. Maybe the person implementing sqrt() was having a bad day and the variable is actually named "headache". sqrt(headache: foo) might be confusing. But if everybody knew their variables would get exposed, it might encourage them to use sensible names for things, which would help everybody in the long run.

I hack *in* Ruby, not *on* Ruby, so maybe there are good technical reasons why this is difficult or not worth doing, but from a user's point of view, I think it would be great.

Ben

17

>If a subclass of Symbol like SelectorSymbol also had a @namespace slot to
>provide selector namespaces (which would be great with Ruby's modules and
>re-opening of classes; SmallScript does something similar), we would also
>need some way to associate a namespace with a selector symbol. e.g.
> x.send :move # which namespace? symbol or selector symbol?
> x.send N1::move # ah, N1's :move selector symbol
> x.send :move # send could treat :move symbol as default_ns::move
>selector symbol?

I'm not sure I get you, but I feel like you're suggesting something
interesting. Let me consider. Detailed explanation would be welcomed.

                                                        matz.

Oooh. I see great potential here. . . Selector namespaces, though. ..
how would they work for normal method calls? I know little about how
they're done in Smalltalk, though I get the concept. I'd love to know
more, too.

18

"Yukihiro Matsumoto" <matz@ruby-lang.org> wrote in message

>If a subclass of Symbol like SelectorSymbol also had a @namespace slot to
>provide selector namespaces (which would be great with Ruby's modules and
>re-opening of classes; SmallScript does something similar), we would also
>need some way to associate a namespace with a selector symbol. e.g.
> x.send :move # which namespace? symbol or selector symbol?
> x.send N1::move # ah, N1's :move selector symbol
> x.send :move # send could treat :move symbol as default_ns::move
>selector symbol?

I'm not sure I get you, but I feel like you're suggesting something
interesting. Let me consider. Detailed explanation would be welcomed.

When defining a method (via def... or define_method) we need to indicate
which namespace the selector belongs to; and when invoking a method via
x.send or x.foo, we need to indicate which namespace selector we are using.

···

--------------
First for invocations of the form: x.send(selector, *args)
#send needs to know the namespace of the selector so it can lookup the
correct method. A subclass of Symbol, say SelectorSymbol, could have a
@namespace slot. NameSpace#lookup(symbol) could return a SelectorSymbol, and
all methods (or unbound methods) could be indexed by SelectorSymbols.

So I can now write in verbose form:
    x.send my_namespace.lookup(:move) other_args

We need a better syntax to indicate which namespace. Something like:
    x.send myns::move other_args # :: resolves to a SelectorSymbol
or
    x.send myns:.move other_args # :. resolves to a SelectorSymbol

If #send receives a regular symbol (instead of a SelectorSymbol), it can
look up the SelectorSymbol from Ruby's current namespace, or from some
global default namespace, or first one then the other.
    x.send :move args
        becomes
    x.send default_ns::move args
        or, as an alternative language design choice
    x.send current_ns::move args

Also, define_method would need very similar logic to index its methods.

--------------
Next, for invocations of the form: x.selector y, z
Given:
    x.move args
Here the compiler/interpreter/vm must know the current namespace and treat
is as equivalent to
    x.send current_ns::move args

--------------
Lastly, we need a way to indicate the current namespace. I believe Ruby
modules are the right unit for this:
module M
    class Desk
        def move # M::move
        end
    end
    class Chair
        def move # also M::move
        end
    end
    x.move #=> x.send M::move
end

However, there may be other conflicts which how modules and module::foo are
used in Ruby that make it necessary to have either a different explicit
namespace construct, or use something like M:.name instead M::name to
resolve selectors.

And we need a namespace "import" which only makes the imported module the
current namespace (i.e. not the same as require and include).

module N
    import M
        n.move # n.send M::move
        class Bed
            def move # N::move or M::move? I think the latter
            end
            def M::move # alternate approach
            end
        end
    end
end

--------------
There are implementations of selector namespaces in SmallScript and Squeak.
I think the SmallScript ones are very good (www.smallscript.com , with
several discussions available via google
selector namespace smallscript - Google Search )

Hope that helps ...

19

"Florian Gross" <flgr@ccan.de> wrote in message
news:33vlj3F45i5rjU1@individual.net...

itsme213 wrote:

>>>other method and parameter meta-data
>>I don't think there's more meta-data than the above.
>
> Not built into Ruby, true. But an app might have its own meta-data,

possibly

> domain-specific. Perhaps things like param types, or data about how
> parameters are interpreted by a method (e.g. "either a list of dates, or

a

> start date and a list of durations "), etc. A domain-specific Ruby could

add

> Class#methods to declare such things.

I think that's outside the scope of the above request.

That aside I think custom meta-data should be implemented via custom
methods on method objects. This would be easier if method objects were
to be cached by Ruby.

My other post in this thread suggests that something like a MethodData
(perhaps better called MethodSignature, or MethodInfo) object, perhaps
combined with a Parameter object, helps as well. We need the same structure
of information from Method, UnboundMethod, Class#instance_methods,
Object#public_methods, etc.

And yes, these could probably be computed from the node tree when required.
It would be nice if they were 'stable' objects, so we could reliably attach
further information to them once Ruby decided to compute and create them.

20

Ben Giddings ha scritto:

I also really like the idea of some kind of MethodData or MethodDescriptor objects that can describe themselves, list their keyword args, list the default values, etc.

notice that you can already do that, to some extent, look in the archives for the docstring hack. It would be even easier if def returned a symbol or a method object as proposed in a RCR.

And while we're at it, I don't see a good reason why every arg shouldn't automatically be a keyword arg.

I'd like this too. Mostly because withouth this one would be forced to choose beetween having keyword arguments or positional ones when writing the function, but matz has different ideas :confused: