I have to agree with T.J. In addition to complexity, there is also a concern for size. If I am using the newest version of the code, why would I want the added weight of compatibility stuff I will never use?
Allen Madsen http://www.allenmadsen.com On Sun, Oct 11, 2009 at 3:25 AM, T.J. Crowder <t...@crowdersoftware.com> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
