correct _.times example in index.html

[dragmove]

hello :) I've discovered issue of example _.times method in index.html file.

I just have changed

_(3).times(function(n){ genie.grantWishNumber(n); });

to

_.times(3, function(n){ genie.grantWishNumber(n); });

.

Always thanks to underscore. :)

[coveralls]

Coverage increased (+1.6%) to 96.763% when pulling a5382ed on dragmove:master into d4f52aa on jashkenas:master.

[captbaritone]

This is a valid, although under-documented syntax in Underscore. See: http://underscorejs.org/#oop.

[craigmichaelmartin]

Sure, and this syntax is even called out before the example. That said, why introduce complexity to someone trying to understand the method? An example of using just the function at hand seems more helpful.

[captbaritone]

Fair point. I think there is a trade off between standardizing the docs around the `_.` Syntax and including examples of the OOP style. Including the OOP examples could help raise awareness of the OOP style, but can be more confusing if you have not come across the OOP style yet. It's kinda a chicken and egg situation. I suppose as core devs we should decide how we want to promote or deprioritize the OOP style. If we want to think of OOP as an equally valid syntax, we should add _more_ examples to the docs. If we want to deprioritize it, we should scrub all examples outside of the OOP-specific docs. One downside of deprioritizing is that when you do come across OOP code in your code base, it can be extremely hard to figure out what's going on. Thoughts? -- Jordan Eldredge (mobile)

…

On May 22, 2017, at 5:38 AM, Craig Martin ***@***.***> wrote: Sure, and this syntax is even called out before the example. That said, why introduce complexity to someone trying to understand the method? An example of using just the function at hand seems more helpful. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub, or mute the thread.

[coveralls]

Coverage increased (+1.6%) to 96.763% when pulling a5382ed on dragmove:master into d4f52aa on jashkenas:master.

[craigmichaelmartin]

My two cents: what is described as the "functional style" is the canonical form; it uses the methods according to the signature they actually have. The OOP style offers a convenient wrapper which just applies the wrapped value to the canonical form. Given that, I would think all examples (except the OOP one) should use the functional style.

If we want to think of OOP as an equally valid syntax, we should add more examples to the docs. If we want to deprioritize it, we should scrub all examples outside of the OOP-specific docs.

Currently the docs treat the functional style as the canonical form - not because of the examples but because each function (eg, each) is exposed as a property on _ (_.each(list, iteratee, [context])) and not as a instance method on an _ instance (see the function header http://underscorejs.org/#each). I think demonstrating the function using an instance of _ with the function under consideration put on the prototype as a mixin is inconsistent with how the function is presented, and introduces unnecessary complexity to understand the example.

One downside of deprioritizing is that when you do come across OOP code in your code base, it can be extremely hard to figure out what's going on.

For sure. I think if we go this route (and actually even if we don't) we should surface the OOP section when querying for _( and ( on the underscore site.

[captbaritone]

@craigmichaelmartin Agreed. Let's do it. I'll merge this and followup with a PR to remove the note about OOP style. Improve searching to account for for _( and ( will take a little bit of shuffling. @dragmove, is that something you would like to look into? The code lives in docs/main.js.