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 
For more options, visit this group at 

Reply via email to