ruby idiom for parsing function arguments?

[zuzu]

this may be a silly question, but can someone provide for me the ruby
idiom for parsing function arguments? it's not hard coded by array
position, is it? is there an idiom for testing arguments for meeting
criteria and the function making sense of what to do with them? for
example, parsing command line arguments which could be flags, a
url/location, a device, or stdin data...

for anyone who has used cdrtools or cdrdao, i would like to avoid
requiring proper ordering, and instead relying on contextual inferance
of what arguments/flags are what (options, data, device/drive, etc.)

tia,
-z

 

[Charles Comstock]

this may be a silly question, but can someone provide for me the ruby
idiom for parsing function arguments? it's not hard coded by array
position, is it? is there an idiom for testing arguments for meeting
criteria and the function making sense of what to do with them? for
example, parsing command line arguments which could be flags, a
url/location, a device, or stdin data...

for anyone who has used cdrtools or cdrdao, i would like to avoid
requiring proper ordering, and instead relying on contextual inferance
of what arguments/flags are what (options, data, device/drive, etc.)

tia,
-z

optparse, getoptslong, getopts::declare are all for parsing commandline
arguments, with optional positional or arbitrary orderings.

Charles Comstock

 

[zuzu]

optparse, getoptslong, getopts::declare are all for parsing commandline
arguments, with optional positional or arbitrary orderings.

Charles Comstock

1.) information on this looks scarce. other than just reading
optparse.rb, if anyone has an URLs on this, please provide them.

2.) i would like to clarify, that this is not necessarily for reading
ruby, the interpreter, or chmod +x .rb files, shell command lines.
this should apply to any function/method's arguments; as in
object.method(arg1, arg2, arg3).

thanks!
-z

 

[Austin Ziegler]

Ruby's method arguments up to 1.8 are positional, with some support for hashes:

foo(bar, baz, :a => a, :b => b)

Your argument list must look something like:

def foo(bar, baz, opts = {}) ...

In Ruby 1.9, there is support for named arguments; I haven't started
using them (I'm still targeting 1.8), so I can't quite tell if they
are a call-only mechanism or a definition mechanism. The call would
look something like:

foo(bar, baz, b: b, a: a)

I remember reading somewhere that hash arguments may be unsupported
moving forward, but I don't know what's the status on that.

 

[Robert Klemme]

2.) i would like to clarify, that this is not necessarily for reading
ruby, the interpreter, or chmod +x .rb files, shell command lines.
this should apply to any function/method's arguments; as in
object.method(arg1, arg2, arg3).

What exactly do you want to do? I mean, you don't have to parse method
arguments since that is taken care of by Ruby.

Btw: see also "Duck Typing".

Regards

robert

 

[zuzu]

What exactly do you want to do? I mean, you don't have to parse method
arguments since that is taken care of by Ruby.

Btw: see also "Duck Typing".

Regards

robert

word. http://c2.com/cgi/wiki?DuckTyping
my initial impression of "duck typing" was equivalent to dynamic
typing, but there seems to be a little more to the mallard definition.
i would appreciate an example of code demonstrating how to introspect
a "hey, what kind of object are you?" message/method.

i'm looking to extend ruby to the actor/dataflow model where instead
of "everything is an object", "everything is an actor". as an
intended side-effect, this should encourage runtime
introspection/reflection and concurrency/parallelization in
programming.

so specifically, if i'm randomly (according to the scheduler) passing
an object/actor dataflow and options as arguments, i would like a
"behaviour script" to successfully differentiate them introspectively
rather than explicitly (by the programmer).

-z

 

[gabriele renzi]

il Mon, 19 Jul 2004 17:15:47 +0900, zuzu <[email protected]> ha
scritto::

word. http://c2.com/cgi/wiki?DuckTyping
my initial impression of "duck typing" was equivalent to dynamic
typing, but there seems to be a little more to the mallard definition.
i would appreciate an example of code demonstrating how to introspect
a "hey, what kind of object are you?" message/method.

look in the archives of the group for exact definition. I think the
definition is quite non strong
anyway:=> true

ypou can use the StrongTyping and types.rb modules to have signature
based dispatch and stuff like that.

i'm looking to extend ruby to the actor/dataflow model where instead
of "everything is an object", "everything is an actor". as an
intended side-effect, this should encourage runtime
introspection/reflection and concurrency/parallelization in
programming.

so specifically, if i'm randomly (according to the scheduler) passing
an object/actor dataflow and options as arguments, i would like a
"behaviour script" to successfully differentiate them introspectively
rather than explicitly (by the programmer).

this sounds good at the first time but it's not really, imho.
the programmer does not have many advantage from this:

MyClass.new 10
MyClass.new '1'

over this:

MyClass.from_int 10
MyClass.from_str '1'

 

[Aredridel]

word. http://c2.com/cgi/wiki?DuckTyping

my initial impression of "duck typing" was equivalent to dynamic
typing, but there seems to be a little more to the mallard definition.
i would appreciate an example of code demonstrating how to introspect
a "hey, what kind of object are you?" message/method.

In essence, I don't: I don't ask what class and object is, I tell it to
represent itself as one when it's important, and just ignore it
otherwise:

not duck typed:

def foo(s)
raise TypeError if !s.kind_of? String
frob(s) << "thing"

end

duck typed:

def foo(s)
frob(s.to_s) << "thing"
end

and even more so:

def foo(s)
frob(s) << "thing"
end

The last one I can point out a unique property: If frob just adds
something to the end of what it's passed with <<, as well, then for all
intents and purposes, I don't have to care whether the parameter is a
string or a file -- or something else entirely. As long as it supports,
in this case, <<, it's all good. I just don't bother checking.

Part of what supports this style well is somewhat functional-style
programming: I to make a few more checks when I store something so that
a backtrace won't reveal its origin. Then, in my code, I try to avoid
needing to store things often.

Good examples of this are WEBrick and many of the other standard
libraries: WEBrick's state is mostly transitory, with a request built,
then passed from method to method as parameters, building a response
which is ultimately returned. Nowhere does the response go into an array
for later retrieval, no queue or anything like that. It melds very well
with duck typing, too -- the response has to respond to a handful of
easily-discoverable methods, and there aren't many odd cases where a
method gets called in only a few situations.

Ari