Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Ruby > A comparison by example of keyword argument styles

Reply
Thread Tools

A comparison by example of keyword argument styles

 
 
Christophe Grandsire
Guest
Posts: n/a
 
      10-22-2005
En r=E9ponse =E0 itsme213 :
>=20
> Their number is part of the signature (rather than their position(s)).
>=20


OK. That's about what I meant .

> > Keyword arguments, being just a
> > part of the name of a method, must be explicitly marked as such
> > by the developer, and shouldn't be allowed to be left out by the
> > user, just like you can't leave out the name of a method.

>=20
> I have always preferred this semantics.
>=20
> It also means keyword argument names must be available through reflecti=

on.
>=20


Indeed, very good remark.
--=20
Christophe Grandsire.

http://rainbow.conlang.free.fr

You need a straight mind to invent a twisted conlang.


 
Reply With Quote
 
 
 
 
Yukihiro Matsumoto
Guest
Posts: n/a
 
      10-22-2005
Hi,

In message "Re: A comparison by example of keyword argument styles"
on Sat, 22 Oct 2005 00:44:58 +0900, Daniel Berger <(E-Mail Removed)> writes:

|> def foo(*args)
|> # how do you delegate arguments?
|> bar(*args)
|> end
|>
|> def bar(a,b,c)
|> p [a,b,c]
|> end
|>
|> foo(1,a:2,c:3)
|
|Not allowed because redefinition of the same parameter raises an error. Here
|you're trying to define 'a' twice, once as the first positional argument, once
|as a named parameter.

Then what if foo(1,b:2,c:3) ?

|Yes, it's uglier. How does it work in your implementation? I'm curious to know
|how you preserve argument order.

For mine, args in foo becomes [1,{:a=>2,:c=>3}]. And suppose

def bar(a:,b:,c
p [a,b,c]
end

since it requires explicit keyword arguments, delegation should be
plain

bar(*args)

and bar prints [1,2,3].

|Let me ask you the same thing. What happens here with your implementation?
|
|class Foo
| def foo(a:, b:, c
| p [a,b,c]
| end
|end
|
|class Bar < Foo
| def foo(d:, e:, f
| super
| end
|end
|
|Bar.new.foo(f:3, e:2, d:1)

Bar#foo receives [{:f=>3,:e=>2,:d=>1}], then it delegates arguments to
Foo#foo. Foo#foo accepts keyword arguments a, b, c, and no other
keywords (it does not have ** in the list), it raises ArgumentError.

matz.


 
Reply With Quote
 
 
 
 
Yukihiro Matsumoto
Guest
Posts: n/a
 
      10-22-2005
Hi,

In message "Re: A comparison by example of keyword argument styles"
on Sat, 22 Oct 2005 03:08:19 +0900, Brian Mitchell <(E-Mail Removed)> writes:

|Matz, are there any patches that implement your proposal yet?

Not yet. The behavior was fixed on a night before the keynote. It is
much easier to implement than one in Sydney though.

matz.


 
Reply With Quote
 
ES
Guest
Posts: n/a
 
      10-22-2005
Yukihiro Matsumoto wrote:
> Hi,
>
> In message "Re: A comparison by example of keyword argument styles"
> on Fri, 21 Oct 2005 20:12:08 +0900, "Daniel Berger" <(E-Mail Removed)> writes:
>
> |Ruby has always favored implicitness over explicitness. The fact that
> |I don't have to do anything explicitly in Sydney makes it the winner
> |IMHO.
>
> Too much implicitness makes code cryptic. Too much explicitness makes
> code verbose. It's a matter of balance.
>
> By the way, how do you delegate the whole arguments (including keyword
> arguments) in your style? Using KeywordBehavior?
>
> Besides, what would happen for the following code?
>
> def foo(*args)
> # how do you delegate arguments?
> bar(*args)
> end
>
> def bar(a,b,c)
> p [a,b,c]
> end
>
> foo(1,a:2,c:3)
>
> and
>
> class Foo
> def foo(a,b,c)
> p [a,b,c]
> end
> end
> class Bar<Foo
> # what if argument names differ?
> def foo(d,e,f)
> super
> end
> end
> Bar.new.foo(d:1,e:2,f:3)


These may not be the best arguments. Two scenarios are possible:

1) foo is supposed to be a transparent proxy: the caller must take care
to call it correctly, like the proxied object/method expects.

2) foo is supposed to present a real interface: the programmer must
take care that the arguments it receives are properly mapped to bar.

In both cases, an error should be raised if keyword arguments are
passed in with nonexistent keywords.

> matz.


E



 
Reply With Quote
 
gga
Guest
Posts: n/a
 
      10-22-2005

Yukihiro Matsumoto ha escrito:

> Hi,
>
> In message "Re: A comparison by example of keyword argument styles"
> on Sat, 22 Oct 2005 03:08:19 +0900, Brian Mitchell <(E-Mail Removed)> writes:
>
> |Matz, are there any patches that implement your proposal yet?
>
> Not yet. The behavior was fixed on a night before the keynote. It is
> much easier to implement than one in Sydney though.
>
> matz.


One question. Why this complexity in syntax? Why the strange and
very confusing ':' as the syntax delimiter in both function definition
and, worse, parameter passing? Sorry, but this just feels so
complicated to me and seems more something thought with ruby's parser
in mind, not the user.

What's wrong with '=' and avoiding defining explicit parameters in the
parameter definition.

Compare everything that was proposed with python's simplicity and
elegance:

# this is something akin to ruby's: def f(*args)
def f2(a, b, c, *d):
print a, b, c, d

# and this is akin to ruby's: def f(arg={})
def f(a, b, c='xxx', **d):
print a, b, c, d

# ---------------

f(1,2,3) # => 1 2 3 {}
f(a=4, b=5, c= # => 4 5 8 {}
f(3, b=5, c= # => 3 5 8 {}
f(b=5, 3) # SyntaxError: non-keyword arg after keyword arg
f(1,2,3, x="hello") # => 1 2 3 {'x' : "hello"}
f(1,2) # => 1 2 xxx {}

f2(1,2, 3, "hello", "a", "c") # => 1 2 3 ( 'hello', 'a', 'c')


There's a lot of things I don't like in python, but how functions are
defined is definitively one of the strongest things in the language.
As you can see above, things are much simpler. No need to use any
special syntax for named parameters in the function definition and the
use of '=' is a heck of a lot more clear than : or =>. Both array and
hash syntaxes for extra parameters are also accounted for.

 
Reply With Quote
 
Trans
Guest
Posts: n/a
 
      10-22-2005
> What's wrong with '=' and avoiding defining explicit parameters in the
> parameter definition.


But = can be used to do assignment at the moment of passing:

def foo(x)
x
end

a = nil

foo (a=1) #=> 1

a #=> 1

T.

 
Reply With Quote
 
Yukihiro Matsumoto
Guest
Posts: n/a
 
      10-22-2005
Hi,

In message "Re: A comparison by example of keyword argument styles"
on Sat, 22 Oct 2005 21:47:05 +0900, "gga" <(E-Mail Removed)> writes:

|What's wrong with '=' and avoiding defining explicit parameters in the
|parameter definition.

Unlike Ruby, assignments are expression in Ruby. Besides that, I
don't think Python keyword arguments are simple and elegant, but YMMV.

matz.


 
Reply With Quote
 
Daniel Schierbeck
Guest
Posts: n/a
 
      10-22-2005
Yukihiro Matsumoto wrote:
> Hi,
>
> In message "Re: A comparison by example of keyword argument styles"
> on Fri, 21 Oct 2005 18:46:59 +0900, Daniel Schierbeck <(E-Mail Removed)> writes:
>
> |1) *Method definition*
> | I think named arguments should have the same
> | syntax as positional ones, just with a colon
> | in front of it.
> |
> | def foo(a, b, :c, :d = "bar")
>
> Why with a colon in front of it instead of right after it?
>
> |2) *Method calling*
> | I think matz' style is preferable in many cases,
> | but i still think the :key = value syntax should
> | be there.
>
> Why should be?
>
> matz.
>
>

Because the keys *are* symbols, and they have colons in front of them.


Cheers,
Daniel
 
Reply With Quote
 
Daniel Schierbeck
Guest
Posts: n/a
 
      10-22-2005
Damphyr wrote:
> The :a syntax looks a lot like symbols ...


Erm, the keywords *are* symbols.

def foo(a: 1, b: 2, **keys)
puts keys[:a] # :a is a symbol!
end

Therefore i think it's more clear if we write the keys as symbols.

def foo(:a = 1, :b = 2, **keys)
puts keys[:a] # foo(:a) -> keys[:a]
end


Cheers,
Daniel
 
Reply With Quote
 
Trans
Guest
Posts: n/a
 
      10-22-2005
> Because the keys *are* symbols, and they have colons in front of them.

But they're *not* symbols. They're local vars.

T.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
RE: keyword checker - keyword.kwlist Hamilton, William Python 4 05-13-2007 06:31 AM
keyword checker - keyword.kwlist tom@finland.com Python 6 05-10-2007 04:53 PM
getting a class attribute using a keyword argument Guy Robinson Python 3 01-19-2005 11:01 PM
keyword argument for min/max Steven Bethard Python 1 11-30-2004 06:02 PM
a question on the new dict() keyword argument syntax Oktay Safak Python 2 08-02-2003 09:12 AM



Advertisments