let devs pick which execution timing to use (don't export too early) about curl HOT 8 CLOSED

Thank you @unscriptable ! I believe you took the right step for curl, as giving more options to developers will allow them to use curl under any circumstance and circumvent some edge cases with some modules.

As for the config property, I vote for: safeLoading: true or saferLoading:true or something that implies the idea of a more foolproof loading process. waitForNextTurn or cascadeAsap are meaningless for someone who is not familiar with curl's internal loading algorithms. But this is just a suggestion. Any identifier will do.

from curl.

@futuresplash

Re: "saferLoading:true"
That name would be good until another, more advanced even more save way of doing it comes up, where it will be called "superSaferLoading:true" , which will be superseded by "uberSuperSaferLoading:true"

Sometime techie name (that describes exactly what setting does) for a setting is better than "itsBetterForYou: true" :)

from curl.

@dvdotsenko I gess you're right! :-)
I'll keep that in mind for my own projects too.
Although I wouldn't mind having a uberSuperSaferLoading method of loading modules in curl!... ;-)

from curl.

Good points on both sides. I'll bet @dvdotsenko has lots of experience building APIs because that's something that's bit me a few times. It's true what they say: "naming is hard". :)

http://blog.millermedeiros.com/2011/07/naming-methods-properties-and-objects/
http://james.padolsey.com/general/making-apis-is-hard/

I'll try to find a name that infers the end benefit without abstracting the implementation too much.

The more important question in my mind is whether to default to waitForNextTurn: true or waitForNextTurn: false. If we default to false, it could lead to developer frustration. If we default to true, one of curl.js's benefits will be lost on many who never read enough of the documentation.

We'll be adding this parameter to the compatibility sections of the wiki ("Using curl.js with XXX"), which could help in either case.

from curl.

@unscriptable

The choices you made so far (judging by how fool-proof our use of curl.js was so far) were stellar. Somehow I fee whatever you pick as per your best opinion will come out just right. (I am not sucking up to you. Stating the fact)

from curl.

I'd be curious as to your reasoning for considering to change the default? Especially if it's for compatibility. Did you run into a bad situation that would warrant the reduced performance?

from curl.

@dvdotsenko thanks!

@asilvas this issue rose out of underscore's initial attempt at AMD compatibility. See issue #36.

There are a few reasons I would consider changing the default: 1) if Chrome is indicative of browsers of the future, the performance difference may be negligible in a few years; 2) in optimized/concatenated files, there is no performance difference; 3) next-turn semantics are increasingly considered "best practices" in server environments.

from curl.

Since the AMDjs fork of underscore fixes the issue, I am removing the milestone on this issue for now.

from curl.