Re: Distinguishing native and host objects

[David-Sarah Hopwood-2]

Brendan Eich wrote:

> On Sep 2, 2009, at 6:15 PM, David-Sarah Hopwood wrote:
>
>> Brendan Eich wrote:
>>> The spec can't yet define these "native wannabe" future standardization
>>> fodder objects, but clearly that's what Allen was thinking of, and it is
>>> well-known to implementors.
>>
>> Why do such things need to have a [[Class]] other than "Object"?
>
> Let's make everything have [[Class]] "Object". Any "private instance
> variables" whose presence is currently guarded by class checks should
> become Name-identified (unforgeable/unguessable property names)
> properties with whatever values are needed. Bonus: you can delegate such
> internal properties to prototypes.
>
> Seriously, this is not the language we have.

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.]

--
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Brendan Eich-3]

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

[1] http://hustlelabs.com/stuff/bh2009_dowd_smith_dewey.pdf
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss