Le 30/12/2012 17:48, Boris Zbarsky a écrit :
On 12/29/12 10:49 PM, Boris Zbarsky wrote:
One other note.
And one last note, promise.
In my opinion, we get too rarely this kind of feedback from implementors
on es-discuss. I'm personally learning a lot.
The point is that SpiderMonkey is working on changing its internal
model to more closely match the spec. And I agree with that approach:
for any somewhat complicated spec, using an internal model that
doesn't match the spec model is just a recipe for pain and
non-conformance. You can try to fake things with enough epicycles,
but like any epicycle setup as soon as you can make more accurate
measurements you have to add more epicycles. That means that things
meant as "specification devices" become de-facto conformance
requirements as specs grow hidden dependencies on those exact
algorithms being used.
True. As far as proxies are concerned, I think it's actually a good
thing. I'll explain that in a separate post soon.
As a simple example, any time someone adds a DOM getter that calls
into page script (assuming there is no such thing already, which I
woudln't be on!) calls to [[GetOwnProperty]] become script-detectable
if DOM properties are value properties (because you have to call the
getter to fill in the descriptor), so if at that point you aren't
implementing exactly the spec's algorithms you're detectably
non-conformant.
And even if you don't call into page script, there are various getters
that have detectable side-effects already (e.g. any of the CSSOM
getters have side-effects on starting times of CSS transitions).
I'm not enough familiar with CSSOM getters and CSS transitions, sorry;
is it a spec requirement or an observation shared for all current
implementations?
As I said in the previous post, some things like innerHTML ought to stay
accessors. The criterion could be whether getting or setting has an
effect observable outside of the object the property is on. So if the
CSSOM spec says some getters have a side-effect on CSS transitions
starting time, let these be accessors.
Thus if you use a specification device in terms of a proxy that
implements getOwnPropertyDescriptor only, suddenly sets of offsetWidth
(a readonly property, note) start having side-effects which they don't
have right now, and implementations that don't have those side-effects
become non-conformant. Again, just as an example of how a
"specification device" can turn into an unintended conformance
requirement.
That'd be a spec bug, but one that is easy to make when unfamiliar with
proxies I agree.
The solution here would be to define the set trap as first performing a
check on whether the property is a readonly one.
Spec bugs can be avoided if a lot of people read the spec and if
interoperability tests are developed. I'm not that worried about
unintended conformance requirement.
I feel that for the vast majority of cases in the web platform, WebIDL
is the only place that'll need to use proxies (exception for live
objects and WindowProxy and probably a handful of other weirdnesses). If
the WebIDL part is done right once, everything will follow fine.
In the upcoming weeks, I'll take a stab at drafting what WebIDL would
look like if defining attributes as own data properties using proxies.
We'll see how it goes.
So I'm very much against using a specification device that doesn't
match the intended implementation, which is what you seem to be
proposing. In my experience, that leads to implementations which
don't actually match the spec in all sorts of edge cases. If we're
lucky, they match each other and all that has to happen is the spec
has to be rewritten somehow. But more commonly they don't match each
other either, and you end up with interoperability problems, which
means your standardization effort just failed...
I haven't been in the web platform for long enough, but I feel now more
people read the specs, catch bugs, discuss, write test cases than
before. I wonder if standardization efforts can "just fail" as much as
they did in the past. I feel spec errors are caught much much earlier
than what I hear from how things were 5+ years ago.
To people who've been there for much longer than me, is it a shared feeling?
David
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
