On 12/31/12 2:24 AM, David Bruant wrote:
Polyfillability is an interesting criteria. Is
Object.getOwnPropertyDescriptor polyfillability important? Would a good
[[Get]]+[[Set]] polyfill be enough? By that I mean that as long as the
[[Get]]+[[Set]] behavior is good, maybe polyfilling a property by
Le 31/12/2012 07:19, Boris Zbarsky a écrit :
On 12/30/12 1:20 PM, Claude Pache wrote:
FWIW, I used the fact that, in IE 8 & 9, innerHTML is conveniently a
configurable accessor found at Element.prototype (in IE8) or
HTMLElement.prototype (in IE9), for correcting a quirk of its setter,
by extra
On 12/30/12 10:53 PM, Brendan Eich wrote:
Think ES1-5 "host objects".
Yeah, anything that needs that sort of thing is already not described as
accessors in WebIDL. Accessors are for the cases which can be
implemented entirely with normal objects plus perhaps WeakMap to store
the not-directl
Boris Zbarsky wrote:
On 12/30/12 10:31 AM, Brandon Benvie wrote:
The problem I see with the accessor model is that it's attempting to use
what's now being referred to in recent ES6 specs as "Ordinary" object
semantics, when the functionality is absolutely of exotic functions.
Can you please de
On 12/30/12 10:58 AM, David Bruant wrote:
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?
The spec requirement is that transitions start when computed values change.
The spec does not defi
On 12/30/12 10:20 AM, David Bruant wrote:
I would say that the difference lies in the fact that properties which
usually materialize the object state clearly are a per-instance thing
while object methods usually are stateless functions
The line is fuzzy (as usual). Is the innerHTML getter more
On 12/30/12 1:20 PM, Claude Pache wrote:
FWIW, I used the fact that, in IE 8 & 9, innerHTML is conveniently a
configurable accessor found at Element.prototype (in IE8) or HTMLElement.prototype
(in IE9), for correcting a quirk of its setter, by extracting it and replacing it
with a corrected ve
On 12/30/12 10:31 AM, Brandon Benvie wrote:
The problem I see with the accessor model is that it's attempting to use
what's now being referred to in recent ES6 specs as "Ordinary" object
semantics, when the functionality is absolutely of exotic functions.
Can you please define "exotic functions
On Sun, Dec 30, 2012 at 7:58 PM, David Bruant wrote:
> To people who've been there for much longer than me, is it a shared feeling?
I think we're still quite bad at tests although it's getting better. I
agree with bz that if specifications diverge from the conceptual model
of implementations or i
Le 30 déc. 2012 à 19:20, David Bruant a écrit :
> Interesting point.
> Unrelated, but it's making me realize that innerHTML may stay a getter/setter
> (not sure about inherited or not).
> I guess the divide I'd like to put is between object state and what is
> conveniently put as an accessor
F
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 workin
The problem I see with the accessor model is that it's attempting to use
what's now being referred to in recent ES6 specs as "Ordinary" object
semantics, when the functionality is absolutely of exotic functions. The
internal functions are no longer magical, as in completely outside the
bounds of wh
Le 30/12/2012 07:42, Boris Zbarsky a écrit :
On 12/29/12 11:08 AM, David Bruant wrote:
Boris, what initially triggered my questioning of the inherited accessor
setting is in this message:
https://mail.mozilla.org/pipermail/es-discuss/2012-December/027435.html
OK, but that's a problem methods c
On 12/29/12 10:49 PM, Boris Zbarsky wrote:
One other note.
And one last note, promise.
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 doe
On 12/29/12 10:42 PM, Boris Zbarsky wrote:
If I'm not misreading the code, it actually hangs its DOM
property getters/setters of the prototype internally, makes them look
like own properties on objects when reflected via
getOwnPropertyDescriptor, and has magic to make a property lookup return
the
On 12/29/12 11:08 AM, David Bruant wrote:
Boris, what initially triggered my questioning of the inherited accessor
setting is in this message:
https://mail.mozilla.org/pipermail/es-discuss/2012-December/027435.html
OK, but that's a problem methods can have too, yes? Not in this
particular cas
David Bruant wrote:
Boris, what initially triggered my questioning of the inherited
accessor setting is in this message:
https://mail.mozilla.org/pipermail/es-discuss/2012-December/027435.html
Mostly concerns about a mix of API "securability" and convenience. I
"demonstrate" that if every attri
Boris, what initially triggered my questioning of the inherited accessor
setting is in this message:
https://mail.mozilla.org/pipermail/es-discuss/2012-December/027435.html
Mostly concerns about a mix of API "securability" and convenience. I
"demonstrate" that if every attribute is an inherited
On 12/28/12 12:31 PM, Boris Zbarsky wrote:
When we have gets through a proxy down in the 20-30 cycle range on
modern hardware, I'm happy to talk about proxies performance-wise. ;)
One other note. I'm somewhat sympathetic to the argument that the spec
could describe things as proxies while ac
On 12/28/12 12:24 PM, Brendan Eich wrote:
David was questioning the new status quo, which is fine -- we benefit
from being skeptical of our theories, as Feynman recommended. He was
motivated by the extra complexity of ES5 accessors, which can be
reflected on, extracted as get and set functions, c
Boris Zbarsky wrote:
All that said, I feel like I'm missing context in this discussion. Why
do we need to change anything about how WebIDL attributes are
reflected? There were good reasons for the current setup, including
the fact that it's somewhat widely deployed already (e.g. implemented
i
On 12/28/12 11:52 AM, Brendan Eich wrote:
Sure, but should all those DOM objects whose pre-WebIDL browser-specific
bindings used magic data properties have to become proxies?
God, I hope not.
Has anyone checked whether doing so is (a) compatible; (b) performant?
It's not performant. It's v
David Bruant wrote:
Pre-WebIDL DOM bindings cheat by using native code to run on every
set and even get, without the own data property reflecting as an
accessor. That seems worse than what we have settled on with
prototype-homed inherited accessors, no?
I'm not 100% sure. In a world with proxie
On Sep 26, 2009, at 3:30 PM, Cameron McCormack wrote:
Yehuda Katz:
Ha. Maybe it would be worth putting a note in HTML5.
"[Replaceable] is
a quirk of history. Do not over-attend to it".
Ian Hickson:
If we start calling out all the quirks of history in HTML5, we'd
probably
end up doubling
Yehuda Katz:
> > Ha. Maybe it would be worth putting a note in HTML5. "[Replaceable] is
> > a quirk of history. Do not over-attend to it".
Ian Hickson:
> If we start calling out all the quirks of history in HTML5, we'd probably
> end up doubling the size of the spec.
OTOH calling out features in
On Fri, 25 Sep 2009, Yehuda Katz wrote:
> On Fri, Sep 25, 2009 at 11:38 PM, Brendan Eich wrote:
> >> I did not single out Replaceable in my efforts to understand.
> >
> > Sure, but it is certainly odd and I wanted to recount some of the history,
> > just so you'd know not to over-attend to it. ;-)
On Fri, 25 Sep 2009, Yehuda Katz wrote:
>
> At the urging of some folks, I've poked around WebIDL and have a few
> observations. I'll use the Window object from HTML as a prop here (it
> is reproduced, in full, below)
If there are issues you would like fixed in HTML5 (as opposed to WebIDL),
pleas
On Sep 25, 2009, at 11:33 PM, Yehuda Katz wrote:
WebIDL, taken as a whole, make it very difficult for someone new to
the spec(s) to understand what's going on. I started, like a
reasonable person, by looking at the Window object. When looking at
it, I encountered a number of somewhat confusing
On Fri, Sep 25, 2009 at 11:38 PM, Brendan Eich wrote:
>> I did not single out Replaceable in my efforts to understand.
>
> Sure, but it is certainly odd and I wanted to recount some of the history,
> just so you'd know not to over-attend to it. ;-)
Ha. Maybe it would be worth putting a note in HT
On Sep 25, 2009, at 11:43 PM, Yehuda Katz wrote:
Do we disagree that it is a worthy goal to have a specification that
can be understood without having to take a while? I certainly
understand the utility in using something with precedent like IDL (for
implementors). Perhaps the IDL version could
I did not single out Replaceable in my efforts to understand.
Sure, but it is certainly odd and I wanted to recount some of the
history, just so you'd know not to over-attend to it. ;-)
WebIDL comes from OMG IDL, much of the precedent is documented in
various online sites, CORBA books, etc
On Fri, Sep 25, 2009 at 11:28 PM, Brendan Eich wrote:
> On Sep 25, 2009, at 11:05 PM, Yehuda Katz wrote:
>
>>> In the ES binding, the properties for these [Replaceable] attributes are
>>> effectively writable, but assigning to them breaks their link to the
>>> original attribute. The assignment d
On Sep 25, 2009, at 11:05 PM, Yehuda Katz wrote:
In the ES binding, the properties for these [Replaceable]
attributes are
effectively writable, but assigning to them breaks their link to the
original attribute. The assignment doesn’t perform any conversion
from
the ES value to the IDL type
Thanks for your responses. They are very useful. First of all, the
length of this response (and the explanations themselves) speak to the
difficulty casual spec readers have in understanding this syntax. More
specific responses inline.
On Fri, Sep 25, 2009 at 10:29 PM, Cameron McCormack wrote:
>
Maciej Stachowiak:
> JS numbers are IEEE doubles, not singles (modulo the
> indistinguishability of different NaNs and other such details).
Right, my mistake.
--
Cameron McCormack ≝ http://mcc.id.au/
___
es-discuss mailing list
es-discuss@mozilla.org
h
On Sep 25, 2009, at 10:29 PM, Cameron McCormack wrote:
unsigned long doesn’t map exactly to Number. Assigning a Number to an
unsigned long attribute does truncation, for example:
http://dev.w3.org/2006/webapi/WebIDL/#es-unsigned-long
The case could be made for “float”, which maps to Number
Boris Zbarsky:
> This I'd like to second. I spent a day or so last week tracing
> through the overload resolution stuff and the general "what happens
> when someone tries to call a method" flow, and it's very difficult
> to follow: lots of jumping back and forth required, for example.
I agree tha
Hi Yehuda.
Yehuda Katz:
> 1. There are a number of ECMAScript-specific extensions here that have
> obscure names and non-obvious behavior. For instance, understanding
> "[Replaceable] readonly" is non-trivial. In fact, "[Replaceable]
> readonly" has somewhat confusing semantics, in that the attrib
38 matches
Mail list logo
