Distinguishing native and host objects
On Sep 2, 2009, at 7:14 PM, David-Sarah Hopwood wrote:
You missed my point. Why do new abstractions need to have a
[[Class]] other than "Object"? The fact that existing abstractions are defined
that way is not a sufficiently good reason.
I'm not sure who missed what, but as I pointed out already, RegExp was
once a non-standard native object (Netscape 4). Ignoring changes for
standardization in ES3, do you contend it should have had class
"Object" when I prototyped it in 1997-1998, and only after ES3 was all
but done in 1999, I should have changed the equivalent of its
[[Class]] to "RegExp"? Or are you arguing against "RegExp" in any
event, if we had all this to do over again?
The obvious approach to handling instance properties is that if a
needed property doesn't exist or is of the wrong type, the algorithm should
throw a TypeError.
Sure. Yet type confusion remains a serious security problem [1]. So
the spec and implementations need something to type-check. If
[[Class]] or its equivalent can't be used, some other type identifier
(on the object, or on the value in an internal property) must be
invented.
Sure, avoiding [[Class]] and inventing some other type identifier or
per-property type tag scheme can be done. The question is why should
it be done for RegExp but not for Date. What's the benefit to
obscuring the real differences between RegExp and Date instances,
which programmers can certainly detect?
Note that once the Harmony class system is in place, we'll
presumably be able to specify new abstractions as if they had been defined using
classes, and I would think that we would certainly want to do it that way,
regardless of historical precedent.
A Harmony class system is not a front-runner for the next significant
(viz, new spec formalism) edition. At the last TC39 meeting we agreed
it should not hold up all the other goodies in reach. So don't assume
it'll be there.
But say we do have class definition syntax for making higher integrity
factories in Harmony. What is the [[Class]] of instances returned by
new C for class C { ... } in your model?
/be
Brendan Eich wrote:
You missed my point. Why do new abstractions need to have a [[Class]] other than "Object"? The fact that existing abstractions are defined that way is not a sufficiently good reason.
The obvious approach to handling instance properties is that if a needed property doesn't exist or is of the wrong type, the algorithm should throw a TypeError.
Note that once the Harmony class system is in place, we'll presumably be able to specify new abstractions as if they had been defined using classes, and I would think that we would certainly want to do it that way, regardless of historical precedent.
[Replies to es-discuss, since this is no longer on-topic for es5-discuss.]