On 27/04/11 19:10, Bemi Faison wrote: > Yes, when compared with the specification, I am using a risky > parameter format. [...] > That said, the current format is not a > "defect", since it works on every major web browser. (Discovering a > JavaScript engine which fails the test suite, would have me say > otherwise.)
What is or isn't a "defect" is entirely subjective. You're not the first author of a JS library who argued that it's alright to rely on unspecified behavior. I refer you to this bug report from 2008, submitted by John Resig about a change in the way V8 iterates over properties: http://code.google.com/p/v8/issues/detail?id=164 You'll notice a great many comments on this bug report arguing for and against the change, but the tl;dr is that the status of the issue remains "WorkingAsIntended". Since then, other major JS engines have adopted similar changes. AFAIK, none of them have bothered to inform their users. This means that while your parameter format works as intended now, it might break at any time in the future, and you wouldn't even receive a warning. Right now, the format you chose _will_ fail in some browsers if one of your users got the idea of using numeric property names. Right now, using (plain) objects instead of arrays will prevent you from modifying an existing Flow at runtime (not sure if that's something you're interested in, though). And right now, paranoid people like me will not look further than this before they dismiss your framework as dangerous, like walking on thin ice. Your idea looks interesting, and you're still at a stage where you can change the parameter format. If you do that now, you'll likely save yourself some headaches in the future. -- stefan -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/[email protected]/ To search via a non-Google archive, visit here: http://www.mail-archive.com/[email protected]/ To unsubscribe from this group, send email to [email protected]
