-
Notifications
You must be signed in to change notification settings - Fork 394
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
Support object keys in addition to arrays #30
Comments
i would be in favor of having them in the same module. when i use promised-io i use allKeys( ) more often than the array methods. but no matter where they end up, i will be happy :) |
Another namespacing option: This also makes me wonder if it's possible to generate the keys methods from their corresponding array methods. I.e. is it possible to generate |
I like the separate module idea. If the key-ified module were to load curl({ packages: [ { name: 'when', location: 'path/to/when', main: 'when/keys' }); // or whatever method your AMD loader uses define(['when'], function (when) {
when.keys.all(objectWithPromisesAsValues, doSomething);
}); |
Interesting idea. Are you thinking that |
i like the namespace idea! but i'm also not sure if "keys" is the right word. when i discovered the allKeys( ) function in promised-io i had to look up the documentation because i had no clue about what that could be. |
+1 for the namespace idea, it avoids cluttering the core |
Cool, thanks for the feedback on the namespace approach. It's probably the direction we'll ... just need to decide on a name :) Some other options:
Other ideas? |
Here's another option. What if when.all/any/some/map/reduce included a test to see if they are dealing with an array or an object, and just "did the right thing"? What are the pros and cons? Some initial thoughts: Pros:
Cons:
Thoughts? |
I just pushed a branch that integrates object key support directly into when.all/any/some/map/reduce. So, you can pass an object or a promise for an object as the first param to any of the above methods, and it will operate on the object's keys/props. Arrays (and promises for arrays) should still all work as before (the unit tests say they do, anyway!) I'm sure there are plenty of botches and edge cases I haven't covered, so the usual caveats apply :) Please try it out and let me know what you think of this versus potentially providing a separate module for object prop support. |
Any reason this hasn't made it to the master? |
Mostly because we've been focused on getting version 2.0 ready, and on other parts of cujo. I think we could probably get this into a 2.1 release. Do you have an immediate need for it? |
We found it to be useful sometimes. We've implemented our own version, but I wonder if this feature would overcomplicate things. I guess not, if you
|
Ok, cool. Yeah, I go back and forth on whether we should integrate it directly into when.all/etc. Lately, I've been feeling like single-purpose methods & functions are the way to go, so, at least right now, I feel like a separate |
@KidkArolis You inspired me :) How does this look? ef1eccb |
Nice! I'm not exactly sure why it's called Also, how would you name this module in your code? I suppose:
|
Here's my thinking on the name when/keys. I considered a few names: when/keys, when/object, and when/props. I decided against when/props because I felt it should behave like Object.keys. Encouraging people to think of the object they pass to these new methods as a simple map or hash seems safer than allowing them to pass complex objects with deep prototype chains that may contain promises--that seems fraught with pitfalls to me. I do like when/object, and it'd make a nice parallel if we ever extract the current array methods to a when/array module. There are 2 reasons I decided to go with when/keys over when/object. First, I think people will tend to name vars like the module name, i.e. var keys vs. var object, or var whenKeys (like you said) vs. var whenObject. Given that, to me, keys.all/map/reduce reads a bit more intuitively than object.all/map/reduce. I feel it communicates specifically that, for example, keys.map will map the keys of whatever you pass to it. Second, I feel it's important to imply that it will only map keys (i.e. own properties), and won't dig into the prototype chain. I think the name when/keys implies that more strongly than when/object. All of that said, I'm def open to other names. I'm even open to rethinking the own props vs. prototype chain decision, if there are (very) compelling reasons. |
Hmmm, does I can still see it being useful, so maybe the right thing is just a BIG DISCLAIMER in the docs? |
Thanks for sharing your thoughts! I like the naming of I would consider removing keys.reduce though? I try to avoid relying on the order in such cases, why allow (encourage?) others to do it by providing this function. I don't think the behaviour is as consistent as you think in most engines, I'm sure I've seen some funky differences when you're adding/removing keys or using numeric keys or something, might be worth investigating more if it can lead to subtle bugs. The prototype chain problem could be handled by a separate function |
Yeah, the key ordering problem seems scary, and could cause some subtle and frustrating bugs. I know at least in Chrome there have been changes to the ordering, some of which involve differences around numeric keys, like you pointed out. You've very nearly convinced me that forcing people to do something like I'll let it stew a bit, and see how I feel. I agree about |
Ugh, underscore and lodash both support reducing object keys :/ |
We could ask them why they think that's ok. |
Ok, after a quick discussion with @unscriptable, and after reading this v8 issue, I'm convinced that, at least for now, |
… well-defined, making reduce a hazard
@unscriptable did end up asking @jdalton briefly about Still, we'll probably launch 2.0 without it and happily add it later if people want (and understand the tradeoffs!) |
The |
On several occasions, I've wanted to use
when.reduce()
on an object's keys rather than on an array, and @sifu recently tweeted something similar aboutwhen.all()
. Also, promised-io providesallKeys()
, in parallel toall()
.It'd be great to find an elegant way to support object keys across all the when.js "array" methods. One approach might be to create equivalent "keys" methods:
allKeys()
,reduceKeys()
, etc., or to provide an additional module that houses the object key versions of those methods.Not sure what is best here, so looking for input, keeping in mind that staying as compact as possible is an important goal :)
The text was updated successfully, but these errors were encountered: