Hi Robert, It's a cool idea, but the complexity starts getting explosive (particularly for unit testing).
If 2.0 is going to have substantial API changes (and I think it is -- Element wrappers, for one), I'd say we should save up the list of things that -- like Joran's units thing, "Enumerable.includes" vs. "Enumerable.include" -- probably should change, and then do them wholescale at that point. My two pence... -- T.J. :-) On Oct 10, 4:36 pm, Robert Kieffer <bro...@gmail.com> wrote: > I'd like to get everyone's opinion on an idea for simplifying the > backward compatibility issues in Prototype. This comes in reaction to > Joran Greef's suggestion that the Prototype API should standardize on > milliseconds as the unit of time passed to methods like Function#delay > () (which currently take seconds): > > http://groups.google.com/group/prototype-core/browse_thread/thread/54... > > Joran's arguments have merit, but as T.J., says "I don't see > changing ... barring a wholescale Prototype API rewrite." This > position is understandable, given how much upheaval API changes cause > in the Prototype community nowadays. But, boy, it sure would be nice > if there were a good compromise! > > To address this issue, I propose adding a "Prototype.Compatibility" > property. It is similar to Prototype.Version, but has a semantic of, > "the desired version of compatibility." By default, this would be set > to the current version: > > Prototype.Compatibility = Prototype.Version; > > Users could set this after importing Prototype to control the behavior > of any API that honored this setting. E.g. To indicate you would > like compatibility with version 1.6 (to the extent possible), you > would do this: > > Prototype.Compatibility = 1.6; > > Internally, methods like delay() could be tweaked to honor this as > follows: > > // Old code: > // timeout = timeout * 1000 > // New code: > timeout *= (Prototype.Compatibility < 2.0 ? 1000 : 1;) > > Please note that I'm being very careful not to imply that Prototype > 2.0 should have a way to achieve across-the-board compatibility with > 1.6. Rather, I'm saying only that there are certain cases where > supporting this property is trivial, and this has the dual benefit of > making it easier to clean up and evolve the Prototype API, while > minimizing compatibility issues for users that upgrade. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Prototype: Core" group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~----------~----~----~----~------~----~------~--~---
