Comments (12)
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.
from core.
My two cents:
options
is much more clear to me and seems to be more of a convention in JS than kwArgs
.
from core.
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.
from core.
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...
from core.
configuration
? though options
tends to be the more common JavaScript name, irrespective of the confusion.
from core.
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
.
from core.
If we're going from one name to conditionally using one of two names, I think we're creating a problem, not solving one...
from core.
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.
from core.
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?
from core.
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.
from core.
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 😄)
from core.
Closing this in lieu of dojo/meta#7.
from core.
Related Issues (20)
- Update tests to Intern 4
- Deprecate (maybe remove) load
- Deprecate lang/assign (and refactor usage)
- old dojox.storage documentation is broken HOT 2
- `utils#throttle()` test fails in Edge HOT 1
- Xhr unit tests intermittently fail on IE11
- I just would like to use dojo2 as a library, it looks a little complex, how could I use it like a react or dojo1? HOT 9
- tslib must be a dependency and not a devDependency HOT 8
- Evented is bloated
- Problem since TypeScript 2.7.1 – Type 'M[keyof M]' does not satisfy the constraint 'EventObject<keyof M>' HOT 9
- UrlSearchParams toString() should not add queryParams if they have no value set
- has.ts causes loading the main bundle to crash in Internet Explorer 11 in https HOT 4
- Support the abortable fetch API HOT 1
- dojo/widget-core typo in code snippet HOT 1
- README: outdated Promise doc
- Docs for UrlSearchParam are wrong
- Upload progress events add preflight request
- Standardize Constructor exports
- Evented listener destroying its own handle won't run all listeners
- lang.mixin errors with null target
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from core.