On Sep 26, 2009, at 10:55 PM, Allen Wirfs-Brock wrote:
-----Original Message-----
From: Cameron McCormack [mailto:c...@mcc.id.au]
...
When writing Web IDL originally, it didn’t seem at all to me that
host
objects were a disapproved of mechanism to get functionality that
can’t
be implemented with native objects. So having a [[Delete]] on a host
object be different from the Object [[Delete]] or the Array one
seemed
fine to me.
The internal methods such as [[Delete]] aren't an actual extension
mechanism.
They are a specification device used to define the semantics of
ECMAScript. As
such they are subject to change (there are significant changes in
the ES5 spec.)
and could even completely disappear if some edition of the ES
specification chooses
to adopt a different specification technique (which has been
discussed).
ES5 seems to imply internal methods are an extension hook by using
them as such for a few built-in types, and by explicitly mentioning
they may behave arbitrarily differently for host objects. ES3 gave
this impression as well. While TC-39 seems to feel differently now, it
was very easy to get the impression by reading the spec that they are
indeed an extension hook. Beyond that, there doesn't seem to be any
other good way to soundly specify the behavior of a host object.
Another issue with using specification internal methods as if they
were an extension
mechanism is that the ECMAScript specifications doesn't define any
abstract contracts
for them. What are the invariants that every [[Delete]] methods
must maintain in order
for the entire language to remain sound? It isn't currently
defined. Within the ES spec.
this isn't a big problem because most of the internal methods only
have one definition
within the ES specification and if there are more than one they have
been designed
with a unified semantics in mind.
Why is functionality that isn't available through native objects
needed? If it is possible
to define Java bindings for WebIDL that don't require extending the
Java language why isn't
it possible to approach JavaScript in the same manner (for new APIs,
I understand the legacy issues).
A) For Web compatibility of pre-existing APIs.
B) In the case of some behaviors already used by pre-existing APIs,
it's useful for new APIs to behave the same way. Some examples: array-
style index access, and traditional details of call and construct
behavior. It would be confusing if every new DOM method behaved
differently from all previous DOM method, or indeed differently from
ECMAScript built-in methods. It would be confusing if all new DOM
constructors were Functions, but old ones aren't. ECMAScript built-in
objects themselves make use some techniques cannot be implemented in
pure ECMAScript, so it seems off-base to me to criticize DOM APIs for
doing the same thing.
[[Delete]] is a different kettle of fish, since overriding its
behavior was not done by either ECMAScript built-ins or any legacy
APIs. But keep in mind, most of the things we're talking about are
already done by Array instances, String objects, built-in
constructors, or built-in methods.
Regards,
Maciej
