kwArgs

[kitsonk]

Are we really wedded to kwArgs instead of something like options?

I know it is a small thing, but honestly I never like the name kwArgs, it just seems like some sort of clique sort of argument name, versus something that is a bit more clear of intent. Thoughts?

[dylans]

No strong opinion here. kwargs comes from Python, and Alex and I had both spent some significant time working with Python just before starting Dojo.

[stdavis]

My two cents:
options is much more clear to me and seems to be more of a convention in JS than kwArgs.

[kfranqueiro]

I could see switching from kwArgs to options since I agree that kwArgs is likely to be foreign to the majority of JS developers.

This will need to be find/replaced in any repos it's used (primarily core). As @kitsonk pointed out in a comment elsewhere, we should probably figure out a good place to mention this in the style guide.

[kfranqueiro]

I suppose my one reservation about the name options is that it makes them sound, well, optional, when some properties in this object may be required...

[kitsonk]

configuration? though options tends to be the more common JavaScript name, irrespective of the confusion.

[bryanforbes]

In some places they are options, but in other places they are things that are mixed into an object. I could see using options for APIs like request() and properties for APIs like Scheduler and DateObject.

[kfranqueiro]

If we're going from one name to conditionally using one of two names, I think we're creating a problem, not solving one...

[bryanforbes]

I'm not sure how being more descriptive with an API is creating a problem. Is it more work for the API writer? Sure. But is it more to learn for an API consumer? Not really. It still behaves the same as kwArgs, but options and properties are more descriptive and describe exactly how the object will be used.

[kfranqueiro]

Coming from Dojo 1's perspective at least, I can't easily think of any places offhand where an object is passed to the constructor and isn't mixed into the instance. And if this question is about deciding what to call a thing, from the perspective of not liking what we call it now, calling it 2 different things seems to be adding more complexity and tending towards "just throw up your hands and call it whatever you feel like in each particular case".

I agree kwArgs is probably awkward to the majority of people, but if we can't come up with an answer that is as simple as what we had before, I'm not sure what value we're adding. Even as a consumer I could fathom looking at API docs and seeing "options" in one place and "properties" in another and stepping back and doing a double-take.

Would just lopping off kw and leaving it at args suffice, or is that too unclear?

[pottedmeat]

I'm a big fan of the "just throw up your hands and call it whatever you feel like in each particular case."

I don't think kwArgs, options, or properties fully encapsulates what they may be used for anyway. If there was a serious desire to capture that, the variable names should be composite (describing what it's for and how it's used), and a bunch of other messy stuff that's probably not needed.

[kitsonk]

I think for downstream code, "just throw up your hands" is ok, but in a toolkit, we have to be specific and provide a guideline and be pedantic about the little things. I find kwArgs terse and not very "JavaScripty" (and @dylans confirmed it was because of familiarity with Python that it ended up in Dojo 1).

I noticed Intern uses config. Does anyone have a moral objection to config or configuration? (I say configuration because I don't want to be accused of being hypocritical about my dislike for terseness to then suggest only config, but I figure if it is good enough for @csnover it is good enough for me 😄)

[kitsonk]

Closing this in lieu of dojo/meta#7.