Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implicit kwargs object? #2475

Closed
leeola opened this issue Aug 1, 2012 · 11 comments
Closed

Implicit kwargs object? #2475

leeola opened this issue Aug 1, 2012 · 11 comments

Comments

@leeola
Copy link

leeola commented Aug 1, 2012

Would it be possible to expose an implicit kwargs, kwargs2, etc object?

For example, currently if you want the kwargs the only .. "clean" way to do it is as follows..

foo = ({bar, baz}) ->
  kwargs = bar: bar, baz: baz
  console.log "kwargs: #{JSON.stringify kwargs}"

Now, the same thing can be achieved without defining kwargs, by using _arg, such as..

foo = ({bar, baz}) ->
  kwargs = _arg
  console.log "kwargs: #{JSON.stringify kwargs}"

But i don't think _arg, _arg1, _arg2, etc, is descriptive enough.. do you? I'm likely in the minority, but wouldn't renaming _arg to kwargs or _kwargs be more intuitive?

I mean, if you know _arg refers to a hidden object variable name, then it is easily made sense of, but if you don't.. the user is left wonder which _arg it is referring to.

@michaelficarra
Copy link
Collaborator

What you're really asking for is Haskell's as-patterns. See http://www.haskell.org/tutorial/patterns.html

I agree, as-patterns are needed.

edit: Also, never refer to those generated variables in your code.

@epidemian
Copy link
Contributor

A cleaner version for doing this is:

foo = (kwargs) ->
  {bar, baz} = kwargs
  console.log "kwargs: #{JSON.stringify kwargs}"

LiveScript lets you name destructuring arguments using a ::

foo = ({bar, baz}:kwargs) ->
  console.log "kwargs: #{JSON.stringify kwargs}"

@leeola
Copy link
Author

leeola commented Aug 3, 2012

@michaelficarra

edit: Also, never refer to those generated variables in your code.

I'm on the fence about this.. If it was implemented as a feature, what would be wrong with it?

Currently i agree, don't use _arg, but if it was considered a feature (and thus, subject to feature-freeze, compatibility, etc), wouldn't it be safe?

Wouldn't _arg or _kwarg roughly the same as using the hidden arguments object?

But none the less, currently i agree.. you have no idea if CoffeeScript will decide to change _arg's implementation/naming/etc. So this post/question is just out of curiosity :)

@michaelficarra
Copy link
Collaborator

@epidemian: That's LiveScript's implementation of as-patterns.

@leeolayvar: Possibly, but you would have to remember complex rules regarding name generation. That's not a feature you would add to your language. Explicitly naming these temporary constructs via as-patterns is far superior.

@epidemian
Copy link
Contributor

One thing that CoffeeScript already is naming deconstructed object properties, like:

foo = ({bar: thebar, baz: thebaz}) ->

But it doesn't let you name that whole deconstructed object.

@leeola
Copy link
Author

leeola commented Aug 3, 2012

@michaelficarra: Fine with me :)

@epidemian: I like your cleaner version. When i want the object name, i think i'll do that for now :)

@leeola
Copy link
Author

leeola commented Aug 3, 2012

@michaelficarra Oh also, as-patterns such as x:xs removes the first element from xs, correct? That's not exactly what my original goal was, but nonetheless i would love that feature in Coffee.

@vendethiel
Copy link
Collaborator

It doesn't, unless you have a value before, ie [first_element, ...elements:rest] (list destructuring)
"as-patterns" are [a, b, c]:elems or {a}:array

@michaelficarra
Copy link
Collaborator

@leeolayvar: No, you're thinking of list destructuring. As-patterns give a name to the object being destructured so both the inner members and the outer container can be referenced.

@leeola
Copy link
Author

leeola commented Aug 3, 2012

Nice :)

@jashkenas
Copy link
Owner

I'm afraid I'm going to be a stick in the mud about cluttering up function signatures as usual. The explicit name of the argument with the destructing below looks best to me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants