Ah... didn't quite grok the __defineGetter/Setter__ calls first time
through. Cool... 'wish I'd known about that at the time. Live and learn I
guess. :-P
On Sun, Oct 11, 2009 at 7:22 PM, Tobie Langel wrote:
>
> > Does that update helper identify where code accessed Hash objects.
>
> Yes, provid
> Does that update helper identify where code accessed Hash objects.
Yes, provided there had been set before.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email
Does that update helper identify where code accessed Hash objects? (Doesn't
look like it.) The 1.5->1.6 upgrade was mostly painless, except for the
Hash API change. And the problem there was that accessing a 1.5 Hash is
done just like a generic JS object, so there was no reliable way to parse
co
[OT] Robert, had you tried the update helper to help out with this
migration?
On Oct 12, 2:34 am, Robert Kieffer wrote:
> Regarding "added weight of compatibility stuff I will never use", one
> of the main reasons I proposed this is that allows devlopers to decide
> on a per-case basis when and
Regarding "added weight of compatibility stuff I will never use", one
of the main reasons I proposed this is that allows devlopers to decide
on a per-case basis when and where to support backward compatibility.
I.e. if the code .vs. benefit analysis doesn't make sense, don't
support it.
T.J, You
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
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.i
