On Thu, Aug 22, 2013 at 4:02 PM, Eldar <eldar...@gmail.com> wrote: > I am sorry, I had to write more detailed explanation of my above > statements. > > *Postel low (Robustness principle)* > > You can have a look at wikipedia article about it > http://en.wikipedia.org/wiki/Robustness_principle. > It contains explanation about why the robustness principle is harmful and > contains a link to the corresponding RFC. > > About browsers. I am not much aware history of browsers wars, but I am > aware about > HTML parsers and what a shit they are and heard about how much efforts it > took to make > all that quirk stuff be a standard. Although browsers had a greater > excuse for that than a pure machine protocols. > > Finally, I personally suffered from "robustness" even within my *private* > tool chain :) >
I'm sorry, but again, this is misguided. The complaint in that article is that by being liberal, you're masking potential problems in the calling code. The only potential problem comes from other API developers begin inconsistent and allowing sometimes-sync callbacks. Whether you want to believe it or not, forcing always sync is both the strict and liberal implementation. It's strict because it guarantees a specific order. It's liberal because it guarantees the caller can't write broken code. So perhaps this isn't the robustness principle exactly, but the fact remains that the safest thing for everyone is always async. *process.nextTick* > * > * > Downsides of process.nextTick are > > 1) It is none-standard, not available in other environments and even can't > be shimed (with promise of the same performance). > We're talking about node. If you're writing a multi-environment module, then all node standards are out. The standard already exists directly in node core. The core team has publicly stated that you should force always async in a thread I already linked to. 2) It has performance costs. Significant or not depends on your use case. > It's quite rare for modules to actually have significant performance costs based on forced async. It does happen, but very rarely. > 3) It disables some use cases. > This cannot be true. You cannot have a sometimes-async API which breaks when not always async. -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
