Re: A comparison by example of keyword argument styles

Trans wrote:

> The 'key: :sym' effect is very unfortunate. I use symbol argument in a
> number of places.

Yes, it’s a bit ugly, but to me, using => for key-value pairs is not
visually pleasing either.  However, I use them all the time when
creating hashes.  How about ‘⇒’?

> Whether I will use them with keys much, who knows, but given the
> problem I probably just won't and may even end up only using => so as
> to avoid it. Then the ':' may as well not exist.

What, we shouldn’t have ‘:’ since you personally will never use it?

If you don’t know how you will be using keyword arguments, then how can
you know if the proposed syntax will cause a visually displeasing
result?  As I said in my other mail on this sub-thread, I think that
we’re making too much of the “but symbol arguments to keyword parameters
will look ugly” issue.

> I don't know. But it sure would be nice if there was a simple fix to
> this.  Perhaps if backticks can become an *additional* way to express
> a symbol? I know they are currently used for a type of system call,
> but I'm sure a regular method would be okay for that. And I don't
> think that's too much to ask of Ruby 2.0. Seems like a reasonble
> solution.

How about "symbol".to_sym?  Personally, I’d love to see Unicode being
used in Ruby’s syntax (OK, I know that it won’t happen, but as long as
we’re on this rather pointless discussion):

• «symbol»
• »symbol«
• »symbol
• ⟨symbol⟩

> Of course there's still the question of Evan vs. Matz keyword
> arguments. 

Named arguments versus keyword arguments, to be more precise, as they
are two different things.  Or have I missed something?

> I can go either way. I think we all pretty much can go either way. We
> know one works fine for Python, we know the other works fine for Lisp.
> Is one truly better than the other? Doesn't seem like it --at least
> not by much. Mostly, they're just different. Pick one.

They are two different things.  Keyword arguments are a cleaner way to
implement methods that take optional parameters.  Instead of writing a
method like

def m(a, b, c = 1)
  ⋮
end

we can write it as

def m(a, b, c: 1)
  ⋮
end

and then at invocation we write

m(1, 2, c: 3)

instead of

m(1, 2, 3)

to make it clear that we are passing an argument to a parameter that is
usually optional.

Named arguments is just a way of naming the parameter to tie the given
argument to.

They seem to be the same thing, but in reality they aren’t.  Personally,
I don’t see the point of naming arguments, as parameters are usually
ordered in a sensible way already (i.e., travel(from, to) is clear
enough; travel(from: from, to: to) doesn’t add anything).  I do,
however, see a point of being able to clearly state what optional
(keyword) parameters I do care about, as this allows me to skip defining
those that I don’t care about:

def m(a, b, c: 1, d: 2)
  ⋮
end

m(1, 2, d: 4)

        nikolai

-- 
Nikolai Weibull: now available free of charge at http://bitwi.se/!
Born in Chicago, IL USA; currently residing in Gothenburg, Sweden.
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}