Should host objects be able to have [[Class]] "Function", "Array" etc.?
On Nov 14, 2008, at 4:48 PM, David-Sarah Hopwood wrote:
David-Sarah Hopwood wrote:
Waldemar Horwat wrote:
Mark S. Miller wrote: [Kona 15.3.4.5]
11. If the [[Class]] property of /G/ is *"Function"*, then 1. Get the *length* property of /G/. 2. Let /L/ be Result(11a) minus the length of /A/.[These substeps are actually labelled a. and b.]
What does "minus" mean here? Result(11a) could be anything.
The 'length' property of a built-in object with [[Class]] "Function" is not Writable or Configurable [Kona 15.3.5.1], so it must be equal to the number it was set to in either [Kona 13.2 step 7] or [Kona 15.3.4.5 step 11c or 12], which are the only places where built-in objects of [[Class]] "Function" are created (and [[Class]] cannot be changed after creation). But that should be explained in a NOTE section.
Caveat: [section 15]
The value of the [[Class]] property of a host object may be any
value,
even a value used by a built-in object for its [[Class]] property.
So any random host object might have [[Class]] "Function" (which is a bug). If that is the case, all bets are off (and in that case steps
11 and 15 of the 'bind' algorithm are broken anyway -- for example, the 'length' or 'prototype' properties of G might not exist).We didn't resolve this.
Should host objects be required not to have [[Class]] "Function"?
No, I do not think this is a sounds requirement. All native functions
in the DOM are host objects, and I think it would be wrong to disallow
them to have [[Class]] "Function", or to prevent any
Function.prototype methods from working on them.
I would find it acceptable to require any host object that has
[[Class]] "Function" to implement the [[Call]] internal property and
to have a read-only non-deletable property named "length" which has a
numeric value.
Should host objects be required not to have [[Class]] "Array", "Boolean", "Date", "Decimal", "JSON", "Math", "Number", "RegExp", or "String"?
I disagree with this requirement as well. For weird web compatibility
reasons, WebKit has a host class that is identical to the native
String class in every way, except that it compares equal to null and
undefined, vended in rare circumstances. I don't think this hurts
soundness of the language and I see no reason to forbid it.
, Maciej
On Fri, Nov 14, 2008 at 8:25 PM, Maciej Stachowiak <mjs at apple.com> wrote:
[...] WebKit has a host class that is identical to the native String class in every way, except that it compares equal to null and undefined, vended in rare circumstances.[...]
== or ===?
Could you say more about this, or point at any existing docs? Could this endanger any of the assumptions made by secure javascript rewriters or verifiers such as Caja or ADsafe?
On Nov 14, 2008, at 8:30 PM, Mark S. Miller wrote:
On Fri, Nov 14, 2008 at 8:25 PM, Maciej Stachowiak <mjs at apple.com>
wrote: [...] WebKit has a host class that is identical to the native String
class in every way, except that it compares equal to null and
undefined, vended in rare circumstances.[...]== or ===?
Both.
Could you say more about this, or point at any existing docs?
Specifically, we expose a "filter" property on CSSStyleDeclaration, in
support of the SVG filter CSS property. However, many sites test for
"filter" to detect support for MSIE's proprietary "filter" property,
which sadly has the same name but completely incompatible syntax.
Thus, we return this kind of magical undetectable string so if tests
don't detect us as IE.
It works basically the same ways as Mozilla's undetectable
document.all, which we also support.
Could this endanger any of the assumptions made by secure javascript
rewriters or verifiers such as Caja or ADsafe?
I wouldn't know, but I don't believe so unless such verifiers expose
the CSS Object Model, in which case this is the least of their worries.
, Maciej
2008/11/14 Maciej Stachowiak <mjs at apple.com>:
On Nov 14, 2008, at 8:30 PM, Mark S. Miller wrote:
On Fri, Nov 14, 2008 at 8:25 PM, Maciej Stachowiak <mjs at apple.com> wrote:
[...] WebKit has a host class that is identical to the native String class in every way, except that it compares equal to null and undefined, vended in rare circumstances.[...]
== or ===?
Both.
It seems that is a false statement. We can test the filter example by comparing it to null using == and === in Webkit:-
javascript:alert('' == document.body.style.filter) javascript:alert(null == document.body.style.filter) both true
javascript:alert(null === document.body.style.filter) javascript:alert('' === document.body.style.filter) both false.
Could you say more about this, or point at any existing docs?
Specifically, we expose a "filter" property on CSSStyleDeclaration, in support of the SVG filter CSS property. However, many sites test for "filter" to detect support for MSIE's proprietary "filter" property, which sadly has the same name but completely incompatible syntax. Thus, we return this kind of magical undetectable string so if tests don't detect us as IE. It works basically the same ways as Mozilla's undetectable document.all, which we also support.
I have doubts that having an empty string would protect scripts. It would seem to cause more harm than good. Where are the scripts that you prevented from breaking?
Garrett
Maciej Stachowiak wrote:
Specifically, we expose a "filter" property on CSSStyleDeclaration, in support of the SVG filter CSS property. However, many sites test for "filter" to detect support for MSIE's proprietary "filter" property, which sadly has the same name but completely incompatible syntax. Thus, we return this kind of magical undetectable string so if tests don't detect us as IE.
If "many" sites are relying on the proprietary IE semantics, then it's a bug in the CSSStyleDeclaration API that it has incompatible semantics. Magical oddball strings won't fix this problem -- the correct long-term fix is to rename the SVG 'filter' property so that it doesn't clash with something that is incompatible and already widely used.
On Nov 14, 2008, at 11:38 PM, David-Sarah Hopwood wrote:
Maciej Stachowiak wrote:
Specifically, we expose a "filter" property on CSSStyleDeclaration,
in support of the SVG filter CSS property. However, many sites test for "filter" to detect support for MSIE's proprietary "filter" property, which sadly has the same name but completely incompatible syntax.
Thus, we return this kind of magical undetectable string so if tests don't detect us as IE.If "many" sites are relying on the proprietary IE semantics, then it's a bug in the CSSStyleDeclaration API that it has incompatible
semantics. Magical oddball strings won't fix this problem -- the correct long- term fix is to rename the SVG 'filter' property so that it doesn't clash with something that is incompatible and already widely used.
Magic oddball strings fixed the sites that were actually broken. We
did not do this just for fun, we ran into actual sites that had this
problem. We don't know of sites that have a problem with the current
behavior.
I agree with you that the SVG 'filter' property should be renamed.
This has been raised many times with the SVG Working Group and they
did not agree. In any case I am not asking for advice on our
compatibility strategy, just explaining it. If you'd like, I would be
happy to raise it with the SVG WG yet again, or you are welcome to do
so yourself.
, Maciej
2008/11/14 Maciej Stachowiak <mjs at apple.com>:
Specifically, we expose a "filter" property on CSSStyleDeclaration, in support of the SVG filter CSS property. However, many sites test for "filter" to detect support for MSIE's proprietary "filter" property, which sadly has the same name but completely incompatible syntax. Thus, we return this kind of magical undetectable string so if tests don't detect us as IE. It works basically the same ways as Mozilla's undetectable document.all, which we also support.
Our undetectable document.all works by returning a different value from the property access depending on whether it's a "detecting" use, like |if (document.all)| -- we don't use a magic falsy object (which I think is a violation of E262, but I'd have to dig into the ToBoolean bits to be sure).
Mike
On Sat, Nov 15, 2008 at 5:19 AM, Mike Shaver <mike.shaver at gmail.com> wrote:
2008/11/14 Maciej Stachowiak <mjs at apple.com>:
Specifically, we expose a "filter" property on CSSStyleDeclaration, in support of the SVG filter CSS property. However, many sites test for "filter" to detect support for MSIE's proprietary "filter" property, which sadly has the same name but completely incompatible syntax. Thus, we return this kind of magical undetectable string so if tests don't detect us as IE. It works basically the same ways as Mozilla's undetectable document.all, which we also support.
Our undetectable document.all works by returning a different value from the property access depending on whether it's a "detecting" use, like |if (document.all)| -- we don't use a magic falsy object (which I think is a violation of E262, but I'd have to dig into the ToBoolean bits to be sure).
It is common knowledge that the "undetectable" document.all is detectable through normal scripting practices.
"all" in document
my.opera.com/hallvors/blog/2008/01/25/document-all-true#comment4543577
The same is true for the filter property:-
"filter" in document.body.style
webkit: true.
Standardizing an MSIE property that works differently than in MSIE creates compatibility problems on the web. A better alternative would be to use a different property name.
On 11/15/2008 09:40 PM, Garrett Smith wrote:
Standardizing an MSIE property that works differently than in MSIE creates compatibility problems on the web. A better alternative would be to use a different property name.
Who is supposed to use the better name here? Mozilla added undetectable document.all support to allow sites that didn't bother testing if the current browser was IE (e.g. via |if (document.all)| type tests) some chance of working. We obviously can't expose the same object under a different name as that would defeat the purpose. It isn't a 100% solution, but often these hacks won't be and don't need to be.
I don't think anybody is suggesting that these properties become part of the standard. It seems to me that a conforming implementation should be able to implement such compatibility hacks though, which is why they were brought up.
On Mon, Nov 17, 2008 at 12:17 PM, Blake Kaplan <mrbkap at gmail.com> wrote:
On 11/15/2008 09:40 PM, Garrett Smith wrote:
Standardizing an MSIE property that works differently than in MSIE creates compatibility problems on the web. A better alternative would be to use a different property name.
Who is supposed to use the better name here? Mozilla added undetectable document.all support to allow sites that didn't bother testing if the current browser was IE (e.g. via |if (document.all)| type tests) some chance of working. We obviously can't expose the same object under a different name as that would defeat the purpose. It isn't a 100% solution, but often these hacks won't be and don't need to be.
Yes, I understand this. It's not perfect, but it helps sites that rely on document.all work. Same thing with marquee.
The better name would be something other than "filter" on a CSSStyleDeclaration. Maybe "svgFilter".
I don't think anybody is suggesting that these properties become part of the standard. It seems to me that a conforming implementation should be able to implement such compatibility hacks though, which is why they were brought up.
Internet Explorer 4 had css filters that predates the SVG filter (AFAIK). SVG filter creates a compatibility problem. Maciej says that they worked around this by having style.filter return undefined, but have that undefined be a special value that is == to "". I think it would be a good idea to raise the issue with the SVG WG. If the SVG WG wants to act in good faith, they should consider creating an alternative property name for browsers, style.svgFilter, for example.
,
Garrett
On Mon, Nov 17, 2008 at 10:32 PM, Garrett Smith <dhtmlkitchen at gmail.com> wrote:
Internet Explorer 4 had css filters that predates the SVG filter (AFAIK). SVG filter creates a compatibility problem. Maciej says that they worked around this by having style.filter return undefined, but have that undefined be a special value that is == to "". I think it would be a good idea to raise the issue with the SVG WG. If the SVG WG wants to act in good faith, they should consider creating an alternative property name for browsers, style.svgFilter, for example.
As Maciej said earlier in this thread, "this has been raised many times with the SVG Working Group and they did not agree". You're free to do so again, but that process has nothing to do with ECMA, or really this list.
Mike
and other list members.
Garrett Smith:
The better name would be something other than "filter" on a CSSStyleDeclaration. Maybe "svgFilter".
Yes, that’s a possible solution to the issue, especially since it’s not particularly likely that many existing SVG documents use CSSStyleDeclaration to look up the 'filter' property at the moment.
I don't think anybody is suggesting that these properties become part of the standard. It seems to me that a conforming implementation should be able to implement such compatibility hacks though, which is why they were brought up.
Internet Explorer 4 had css filters that predates the SVG filter (AFAIK). SVG filter creates a compatibility problem. Maciej says that they worked around this by having style.filter return undefined, but have that undefined be a special value that is == to "". I think it would be a good idea to raise the issue with the SVG WG. If the SVG WG wants to act in good faith, they should consider creating an alternative property name for browsers, style.svgFilter, for example.
I forwarded Maciej’s earlier mail to the SVG WG list for discussion:
lists.w3.org/Archives/Public/public-svg-wg/2008OctDec/0377.html
and an issue has been raised:
lists.w3.org/Archives/Public/public-svg-wg/2008OctDec/0384.html
On Nov 17, 2008, at 7:32 PM, Garrett Smith wrote:
On Mon, Nov 17, 2008 at 12:17 PM, Blake Kaplan <mrbkap at gmail.com>
wrote:I don't think anybody is suggesting that these properties become
part of the standard. It seems to me that a conforming implementation should be
able to implement such compatibility hacks though, which is why they were
brought up.Internet Explorer 4 had css filters that predates the SVG filter (AFAIK). SVG filter creates a compatibility problem. Maciej says that they worked around this by having style.filter return undefined, but have that undefined be a special value that is == to "".
No, that's not it. It returns special string value that converts to
boolean as false and compares equal to undefined despite being a
string and possibly non-empty.
I think it would be a good idea to raise the issue with the SVG WG. If the SVG WG wants to act in good faith, they should consider creating an alternative property name for browsers, style.svgFilter, for example.
The issue has been raised with them.
, Maciej
Blake Kaplan wrote:
On 11/15/2008 09:40 PM, Garrett Smith wrote:
Standardizing an MSIE property that works differently than in MSIE creates compatibility problems on the web. A better alternative would be to use a different property name.
Who is supposed to use the better name here?
I can't speak for Garrett Smith, but I think the above comment was mainly about 'filter'. In that case, the SVG WG were supposed to check whether they treading on an existing widely-used (and documented, if proprietary) property name, before standardizing their version. That they did not do so was a perfectly avoidable mistake.
Note that Safari's 'filter' hack has several undesirable properties that document.all does not have:
-
it is enabled even in 'standards mode'; document.all is only enabled in 'quirks mode'.
-
it produces an oddball primitive value, with typeof "string". This is more problematic than an oddball host object; the latter are two-a-penny.
-
the oddball string can escape to code that doesn't know where it came from. The nonstandard behaviour of 'document.all', if I understand correctly, only applies when that property reference is used directly in a boolean context, and so it can't escape to other code.
-
it breaks feature-testing for the standardized version of 'filter', since 'if (document.body.style.filter)' does not work. Renaming the standardized version, say to 'svgFilter', would have avoided this breakage, i.e. 'if (document.body.style.svgFilter)' would then work as expected.
I don't think anybody is suggesting that these properties become part of the standard. It seems to me that a conforming implementation should be able to implement such compatibility hacks though, which is why they were brought up.
If that were intended to be allowed, then ES3.1 would have to be changed to specifically allow it. (One way to do so would be to replace 'ToBoolean' with a [[ToBoolean]] method, that host objects, and only host objects, can override -- although I have not thought about possible side-effects of this approach, and this post should not be taken as recommending it.)
In ES3, the 'document.all' and 'filter' hacks are both clearly nonconformant, because an IfStatement checks only the result of ToBoolean applied to its condition, and ToBoolean is required to return true for all objects and non-zero-length strings.
Mike Shaver wrote:
On Mon, Nov 17, 2008 at 10:32 PM, Garrett Smith <dhtmlkitchen at gmail.com> wrote:
Internet Explorer 4 had css filters that predates the SVG filter (AFAIK). SVG filter creates a compatibility problem. Maciej says that they worked around this by having style.filter return undefined, but have that undefined be a special value that is == to "". I think it would be a good idea to raise the issue with the SVG WG. If the SVG WG wants to act in good faith, they should consider creating an alternative property name for browsers, style.svgFilter, for example.
As Maciej said earlier in this thread, "this has been raised many times with the SVG Working Group and they did not agree".
Browser implementors have the option to refuse to implement that property until they do agree.
David-Sarah Hopwood wrote:
In ES3, the 'document.all' and 'filter' hacks are both clearly nonconformant, because an IfStatement checks only the result of ToBoolean applied to its condition, and ToBoolean is required to return true for all objects and non-zero-length strings.
... and note that this is regardless of the value of the object's [[Class]] property, and so these hacks are not relevant to the original topic of the thread. Specifically, an object with [[Class]] "Boolean" and [[value]] false must still return true from ToBoolean, and must be treated as true in an 'if' condition. Similarly for any object with [[Class]] "String".
On Nov 17, 2008, at 8:38 PM, David-Sarah Hopwood wrote:
Blake Kaplan wrote:
On 11/15/2008 09:40 PM, Garrett Smith wrote:
Standardizing an MSIE property that works differently than in MSIE creates compatibility problems on the web. A better alternative
would be to use a different property name.Who is supposed to use the better name here?
I can't speak for Garrett Smith, but I think the above comment was mainly about 'filter'. In that case, the SVG WG were supposed to check whether they treading on an existing widely-used (and documented, if proprietary) property name, before standardizing their version. That they did not do so was a perfectly avoidable mistake.
Note that Safari's 'filter' hack has several undesirable properties that document.all does not have:
- it is enabled even in 'standards mode'; document.all is only enabled in 'quirks mode'.
That's true in Firefox, but not in Safari. We try to limit quirks to
CSS, rendering and parsing and generally do not let quirks mode affect
scripting behavior.
- it produces an oddball primitive value, with typeof "string". This is more problematic than an oddball host object; the latter are two-a-penny.
No, it's an oddball host object, not an oddball primitive. It's a kind
of String object, not a string value.
- the oddball string can escape to code that doesn't know where it came from. The nonstandard behaviour of 'document.all', if I understand correctly, only applies when that property reference is used directly in a boolean context, and so it can't escape to other code.
That is true (though it also applies to the Safari/WebKit version of
the document.all hack, since we return a falsy object in that case
rather than changing evaluation in boolean contexts only).
- it breaks feature-testing for the standardized version of 'filter', since 'if (document.body.style.filter)' does not work. Renaming the standardized version, say to 'svgFilter', would have avoided this breakage, i.e. 'if (document.body.style.svgFilter)' would then work as expected.
I agree that would be good, and I hope the SVG Working Group considers
it but continuing to discuss it here seems off topic to me.
I don't think anybody is suggesting that these properties become
part of the standard. It seems to me that a conforming implementation
should be able to implement such compatibility hacks though, which is why they were brought up.If that were intended to be allowed, then ES3.1 would have to be changed to specifically allow it. (One way to do so would be to replace 'ToBoolean' with a [[ToBoolean]] method, that host objects, and only host objects, can override -- although I have not thought about possible side-effects of this approach, and this post should not be taken as recommending it.)
In ES3, the 'document.all' and 'filter' hacks are both clearly nonconformant, because an IfStatement checks only the result of ToBoolean applied to its condition, and ToBoolean is required to return true for all objects and non-zero-length strings.
I would prefer that ES3.1 be lenient enough to allow these kinds of
hacks, one way or another. It is unlikely they will be removed, so
there's no benefit to anyone for the standard to claim they are not
allowed.
, Maciej
Maciej Stachowiak wrote:
On Nov 14, 2008, at 4:48 PM, David-Sarah Hopwood wrote:
David-Sarah Hopwood wrote:
Caveat: [section 15]
The value of the [[Class]] property of a host object may be any value,
even a value used by a built-in object for its [[Class]] property.
So any random host object might have [[Class]] "Function" (which is a bug). If that is the case, all bets are off (and in that case steps 11 and 15 of the 'bind' algorithm are broken anyway -- for example, the 'length' or 'prototype' properties of G might not exist).
We didn't resolve this.
We still didn't resolve this.
If it is not fixed by requiring host objects not to have [[Class]] "Function", then the bind algorithm must be fixed in some other way. So must all of the other bugs in ES3 that result from assumptions about objects with [[Class]] "Date" or "RegExp" having all of the properties and behaviour of those types, in sections 15.5.4.{10,11,12,14}, and in the specifications of Date and RegExp methods.
Should host objects be required not to have [[Class]] "Function"?
No, I do not think this is a sounds requirement. All native functions in the DOM are host objects, and I think it would be wrong to disallow them to have [[Class]] "Function", or to prevent any Function.prototype methods from working on them.
I would find it acceptable to require any host object that has [[Class]] "Function" to implement the [[Call]] internal property and to have a read-only non-deletable property named "length" which has a numeric value.
The "prototype" property is also used. I haven't checked what is assumed about it.
Should host objects be required not to have [[Class]] "Array", "Boolean", "Date", "Decimal", "JSON", "Math", "Number", "RegExp", or "String"?
In fact [[Class]] is only checked for the values "Function", "Date" and "RegExp", so it would be sufficient to disallow those values for the [[Class]] of a host object. (OTOH, allowing the other values in the list is not necessary, since the only effect would be on the default implementation of toString(), which could be overridden anyway.)
Note that this means that the comments about host objects emulating arrays were not relevant; they would still be able to with this restriction.
I disagree with this requirement as well. For weird web compatibility reasons, WebKit has a host class that is identical to the native String class in every way, except that it compares equal to null and undefined, vended in rare circumstances. I don't think this hurts soundness of the language and I see no reason to forbid it.
We've now established that this argument is also not relevant to the question about [[Class]], since having one of the above list of [[Class]]es would not help to make either WebKit's string-like host object or SpiderMonkey's document.all conformant.
On Nov 17, 2008, at 9:24 PM, David-Sarah Hopwood wrote:
Maciej Stachowiak wrote:
On Nov 14, 2008, at 4:48 PM, David-Sarah Hopwood wrote:
Should host objects be required not to have [[Class]] "Function"?
No, I do not think this is a sounds requirement. All native
functions in the DOM are host objects, and I think it would be wrong to disallow
them to have [[Class]] "Function", or to prevent any Function.prototype methods from working on them.I would find it acceptable to require any host object that has
[[Class]] "Function" to implement the [[Call]] internal property and to have a read-only non-deletable property named "length" which has a numeric
value.The "prototype" property is also used. I haven't checked what is
assumed about it.
Host functions in the DOM do not generally have a "prototype"
property, because they generally cannot be invoked as constructors.
However, I think all functions that operate on functions should accept
these native functions. I think this is best dealt with by making the
bind algorithm more generic.
, Maciej
On Tue, Nov 18, 2008 at 3:32 AM, Maciej Stachowiak <mjs at apple.com> wrote:
Host functions in the DOM do not generally have a "prototype" property, because they generally cannot be invoked as constructors. However, I think all functions that operate on functions should accept these native functions. I think this is best dealt with by making the bind algorithm more generic.
More generic than the one in the Kona draft? How? As written, it will curry anything with a [[Call]] property. It conditions whether to use the 'prototype' and 'length' properties of the original based on whether the original's [[Class]] is "Function". And it will curry the original's [[Construct]] property only if the original has a [[Construct]] property. I had hoped we could agree to make it less generic -- all these conditionals are troublesome. But how would you make it more generic?
I also don't see a problem with David-Sarah's suggestion of forbidding host objects from having [[Class]] "Function". Most places in the spec care only about whether something is callable (has a [[Call]] property), not whether it has [[Class]] "Function".
On Nov 18, 2008, at 11:00 AM, Mark S. Miller wrote:
On Tue, Nov 18, 2008 at 3:32 AM, Maciej Stachowiak <mjs at apple.com>
wrote:Host functions in the DOM do not generally have a "prototype"
property, because they generally cannot be invoked as constructors.
However, I think all functions that operate on functions should
accept these native functions. I think this is best dealt with by
making the bind algorithm more generic.More generic than the one in the Kona draft? How? As written, it
will curry anything with a [[Call]] property. It conditions whether
to use the 'prototype' and 'length' properties of the original based
on whether the original's [[Class]] is "Function". And it will curry
the original's [[Construct]] property only if the original has a
[[Construct]] property. I had hoped we could agree to make it less
generic -- all these conditionals are troublesome. But how would you
make it more generic?
If the current version doesn't assume anything about the possible
value and attributes of the "prototype" property then that shouldn't
be a problem.
I also don't see a problem with David-Sarah's suggestion of
forbidding host objects from having [[Class]] "Function". Most
places in the spec care only about whether something is callable
(has a [[Call]] property), not whether it has [[Class]] "Function".
It seems arbitrary to me that functions implemented in native code
("internal functions" in ECMA-262 terms) that are part of the
ECMAScript spec must have the [[Class]] "Function", but any that are
not specified there (and are perhaps specified elsewhere) would be
required not to have [[Class]] "Function". Why should Math.random be
required to have [[Class]] "Function", but document.getElementById or
Math.myImplementationExtension be required not to? Do you really think
it makes sense to determine whether something is a function by whether
it is mentioned in the ECMAScript spec?
(Note also that Math.random has [[Class]] "Function" but not a
"prototype" property.)
, Maciej
On Nov 19, 2008, at 6:08 AM, Maciej Stachowiak wrote:
I also don't see a problem with David-Sarah's suggestion of
forbidding host objects from having [[Class]] "Function". Most
places in the spec care only about whether something is callable
(has a [[Call]] property), not whether it has [[Class]] "Function".It seems arbitrary to me that functions implemented in native code
("internal functions" in ECMA-262 terms) that are part of the
ECMAScript spec must have the [[Class]] "Function", but any that are
not specified there (and are perhaps specified elsewhere) would be
required not to have [[Class]] "Function". Why should Math.random be
required to have [[Class]] "Function", but document.getElementById
or Math.myImplementationExtension be required not to? Do you really
think it makes sense to determine whether something is a function by
whether it is mentioned in the ECMAScript spec?
That's silly, not only because of inclusion or location in spec being
immaterial, but also because of gratuitous differences between host
and native implementations even assuming the partitioning between them
is fixed forever.
It does seem worth addressing the variation among browsers where IE's
alert is not a function -- has typeof-type "object" -- while it is
"function" and has [[Class]] "Function" by all measures in other
browsers I'm familiar with. This is considered an IE misfeature, AFAICT.
The original Netscape 2 implementation I did in 1995 wrapped the same
function clothing around native and "host" functions.
Does anyone know of other DOM implementations that differentiate
detectably between host and native functions? Excluding exceptional
cases such as Mozilla's LiveConnect proxy objects that represent
overloaded Java methods, e.g.
(Note also that Math.random has [[Class]] "Function" but not a
"prototype" property.)
Yeah, that's something I missed in ES1 days, which must have come from
JScript. The original Netscape JS implementation then, and
SpiderMonkey still, both give native functions .prototype properties
(bug bugzilla.mozilla.org/show_bug.cgi?id=445319).
On Wed, Nov 19, 2008 at 11:28 AM, Brendan Eich <brendan at mozilla.com> wrote:
On Nov 19, 2008, at 6:08 AM, Maciej Stachowiak wrote:
I also don't see a problem with David-Sarah's suggestion of forbidding host objects from having [[Class]] "Function". Most places in the spec care only about whether something is callable (has a [[Call]] property), not whether it has [[Class]] "Function".
It seems arbitrary to me that functions implemented in native code ("internal functions" in ECMA-262 terms) that are part of the ECMAScript spec must have the [[Class]] "Function", but any that are not specified there (and are perhaps specified elsewhere) would be required not to have [[Class]] "Function". Why should Math.random be required to have [[Class]] "Function", but document.getElementById or Math.myImplementationExtension be required not to? Do you really think it makes sense to determine whether something is a function by whether it is mentioned in the ECMAScript spec?
That's silly, not only because of inclusion or location in spec being immaterial, but also because of gratuitous differences between host and native implementations even assuming the partitioning between them is fixed forever.
It does seem worth addressing the variation among browsers where IE's alert is not a function -- has typeof-type "object" -- while it is "function" and has [[Class]] "Function" by all measures in other browsers I'm familiar with. This is considered an IE misfeature, AFAICT.
yes, I would consider it as such.
I would also consider making a collection a callable object a poor design decision.
What I'm talking about is things like:-
document.all("myDiv");
The original Netscape 2 implementation I did in 1995 wrapped the same function clothing around native and "host" functions.
Does anyone know of other DOM implementations that differentiate detectably between host and native functions? Excluding exceptional cases such as Mozilla's LiveConnect proxy objects that represent overloaded Java methods, e.g.
Some versions of Opera will return "object" for some host objects that implement [[Call]]; other versions return "function"
javascript:var f = document.forms; f(0); alert(typeof f);
Opera 9.5, IE: "object" Safari 3: "function"
Firefox: Error
javascript:var f = document.all; f(0); alert(typeof f); Opera 9.5, Safari 3: "undefined"
IE: "object"
Firefox: Error (Standards Mode)
A native object that implements [[Call]] is supposed to return "function". That is mostly true, with the exception of regexp in FF. With a host object that implements call, the result cannot be determined.
Garrett
Maciej Stachowiak wrote:
On Nov 18, 2008, at 11:00 AM, Mark S. Miller wrote:
I also don't see a problem with David-Sarah's suggestion of forbidding host objects from having [[Class]] "Function". Most places in the spec care only about whether something is callable (has a [[Call]] property), not whether it has [[Class]] "Function".
It seems arbitrary to me that functions implemented in native code ("internal functions" in ECMA-262 terms) that are part of the ECMAScript spec must have the [[Class]] "Function", but any that are not specified there (and are perhaps specified elsewhere) would be required not to have [[Class]] "Function".
It is perfectly possible for a function specified elsewhere to be a native Function object (and to have whatever other methods and properties that 'elsewhere' specifies for it). There is little reason to define callable non-functions, since functions are flexible enough.
On Nov 19, 2008, at 11:37 PM, David-Sarah Hopwood wrote:
Maciej Stachowiak wrote:
On Nov 18, 2008, at 11:00 AM, Mark S. Miller wrote:
I also don't see a problem with David-Sarah's suggestion of
forbidding host objects from having [[Class]] "Function". Most places in the
spec care only about whether something is callable (has a [[Call]] property), not whether it has [[Class]] "Function".It seems arbitrary to me that functions implemented in native code ("internal functions" in ECMA-262 terms) that are part of the
ECMAScript spec must have the [[Class]] "Function", but any that are not
specified there (and are perhaps specified elsewhere) would be required not to have [[Class]] "Function".It is perfectly possible for a function specified elsewhere to be a native Function object (and to have whatever other methods and properties that 'elsewhere' specifies for it). There is little reason to define callable non-functions, since functions are flexible enough.
At least by the definitions of Host object, Native object and Built-in
object, any object "supplied by the host environment" rather than "
supplied by an ECMAScript implementation, independent of the host
environment" is a Host object. It's true that this is a vague
criterion, and an implementation could call anything it wants a native
object instead of a host object by creatively interpreting what is
part of the "ECMAScript implementation" and what is the "host
environment". But arguably such a loophole would make any requirement
on the [[Class]] value of host objects pretty weak, since native
objects could still do whatever they want.
I think what we really want for [[Class]] "Function" is a particular
interface (callable and perhaps has a read-only "length" property with
integer numeric value), not any rule based on whether the object is
native or host.
, Maciej
Maciej Stachowiak wrote:
On Nov 19, 2008, at 11:37 PM, David-Sarah Hopwood wrote:
Maciej Stachowiak wrote:
On Nov 18, 2008, at 11:00 AM, Mark S. Miller wrote:
I also don't see a problem with David-Sarah's suggestion of forbidding host objects from having [[Class]] "Function". Most places in the spec care only about whether something is callable (has a [[Call]] property), not whether it has [[Class]] "Function".
It seems arbitrary to me that functions implemented in native code ("internal functions" in ECMA-262 terms)
There's no such thing as an "internal function", in ECMA-262 terms. You presumably meant "callable host objects" here.
that are part of the ECMAScript spec must have the [[Class]] "Function", but any that are not specified there (and are perhaps specified elsewhere) would be required not to have [[Class]] "Function".
It is perfectly possible for a function specified elsewhere to be a native Function object (and to have whatever other methods and properties that 'elsewhere' specifies for it). There is little reason to define callable non-functions, since functions are flexible enough.
At least by the definitions of Host object, Native object and Built-in object, any object "supplied by the host environment" rather than " supplied by an ECMAScript implementation, independent of the host environment" is a Host object.
You're misreading this. Any object provided by a host API (such as the DOM in browsers) can be a native object. It would be ridiculous not to allow that: what advantage would there be in prohibiting a DOM implementation or other API from being written partly in ECMAScript, or behaving exactly as if it were partly written in ECMAScript?
David-Sarah Hopwood wrote:
Maciej Stachowiak wrote:
It seems arbitrary to me that functions implemented in native code ("internal functions" in ECMA-262 terms)
There's no such thing as an "internal function", in ECMA-262 terms.
Sorry, I'm mistaken here. Just ignore this; it wasn't relevant to the rest of my argument.
On Nov 20, 2008, at 12:24 AM, David-Sarah Hopwood wrote:
Maciej Stachowiak wrote:
On Nov 19, 2008, at 11:37 PM, David-Sarah Hopwood wrote:
Maciej Stachowiak wrote:
On Nov 18, 2008, at 11:00 AM, Mark S. Miller wrote:
I also don't see a problem with David-Sarah's suggestion of
forbidding host objects from having [[Class]] "Function". Most places in
the spec care only about whether something is callable (has a [[Call]] property), not whether it has [[Class]] "Function".It seems arbitrary to me that functions implemented in native code ("internal functions" in ECMA-262 terms)
There's no such thing as an "internal function", in ECMA-262 terms. You presumably meant "callable host objects" here.
No. See "10.1.1 Function Objects" in ECMA-262 3rd edition.
"Internal functions are built-in objects of the language, such as
parseInt and Math.exp. An implementation may also provide
implementation-dependent internal functions that are not described in
this specification."
that are part of the ECMAScript spec must have the [[Class]] "Function", but any that are not
specified there (and are perhaps specified elsewhere) would be required not
to have [[Class]] "Function".It is perfectly possible for a function specified elsewhere to be a native Function object (and to have whatever other methods and properties that 'elsewhere' specifies for it). There is little
reason to define callable non-functions, since functions are flexible
enough.At least by the definitions of Host object, Native object and Built- in object, any object "supplied by the host environment" rather than " supplied by an ECMAScript implementation, independent of the host environment" is a Host object.
You're misreading this. Any object provided by a host API (such as the DOM in browsers) can be a native object. It would be ridiculous not to allow that: what advantage would there be in prohibiting a DOM implementation or other API from being written partly in ECMAScript, or behaving exactly as if it were partly written in ECMAScript?
However, "internal functions" do not behave exactly as if they were
written in ECMAScript. That is exactly the point of the concept.
At this point I will concede it is unclear whether an internal
function that is part of a host API is a native or host object. But I
am pretty sure they have just as much right to have [[Class]]
"Function" as Math.random.
, Maciej
Maciej Stachowiak wrote:
On Nov 20, 2008, at 12:24 AM, David-Sarah Hopwood wrote:
Maciej Stachowiak wrote:
On Nov 19, 2008, at 11:37 PM, David-Sarah Hopwood wrote:
Maciej Stachowiak wrote:
On Nov 18, 2008, at 11:00 AM, Mark S. Miller wrote:
I also don't see a problem with David-Sarah's suggestion of forbidding host objects from having [[Class]] "Function". Most places in the spec care only about whether something is callable (has a [[Call]] property), not whether it has [[Class]] "Function".
It seems arbitrary to me that functions implemented in native code ("internal functions" in ECMA-262 terms)
There's no such thing as an "internal function", in ECMA-262 terms. You presumably meant "callable host objects" here.
No. See "10.1.1 Function Objects" in ECMA-262 3rd edition.
Yes, I corrected this in a follow-up. But internal functions by that definition are native Function objects, so they are not relevant to the argument about host objects. They only differ from non-internal Function objects by having a [[Call]] method that executes non-ECMAScript code, and by being excluded from the discussion of Execution Contexts in chapter 10.
On Nov 20, 2008, at 1:39 AM, David-Sarah Hopwood wrote:
Maciej Stachowiak wrote:
On Nov 20, 2008, at 12:24 AM, David-Sarah Hopwood wrote:
Maciej Stachowiak wrote:
On Nov 19, 2008, at 11:37 PM, David-Sarah Hopwood wrote:
Maciej Stachowiak wrote:
On Nov 18, 2008, at 11:00 AM, Mark S. Miller wrote:
I also don't see a problem with David-Sarah's suggestion of forbidding host objects from having [[Class]] "Function". Most places in
the spec care only about whether something is callable (has a [[Call]] property), not whether it has [[Class]] "Function".It seems arbitrary to me that functions implemented in native
code ("internal functions" in ECMA-262 terms)There's no such thing as an "internal function", in ECMA-262 terms. You presumably meant "callable host objects" here.
No. See "10.1.1 Function Objects" in ECMA-262 3rd edition.
Yes, I corrected this in a follow-up. But internal functions by that definition are native Function objects, so they are not relevant to the argument about host objects. They only differ from non-internal Function objects by having a [[Call]] method that executes non- ECMAScript code, and by being excluded from the discussion of Execution
Contexts in chapter 10.
If all non-ECMAScript-coded methods in the DOM, or other add-on
interfaces, can be Native internal functions rather than Host objects,
even if they have behavior that does not match any predefined native
Function, then I am not sure what a requirement for Host objects not
to have [[Class]] "Function" would achieve.
, Maciej
On Thu, Nov 20, 2008 at 1:43 AM, Maciej Stachowiak <mjs at apple.com> wrote:
If all non-ECMAScript-coded methods in the DOM, or other add-on interfaces, can be Native internal functions rather than Host objects, even if they have behavior that does not match any predefined native Function, then I am not sure what a requirement for Host objects not to have [[Class]] "Function" would achieve.
Native internal functions are still required to satisfy the function contract, including that they inherit from a Function.prototype, while host objects are exempt from almost any contractual terms. The requirement would mean that [[Class]] "Function" becomes a reliable indicator that we have an object that obeys the function contract.
David-Sarah Hopwood wrote:
We didn't resolve this.
Should host objects be required not to have [[Class]] "Function"?
Should host objects be required not to have [[Class]] "Array", "Boolean", "Date", "Decimal", "JSON", "Math", "Number", "RegExp", or "String"?
(I have not included "Error" on this list because it is reasonable for an implementation to add new error types, which would be host objects because they are not described in the standard. All existing error types have [[Class]] "Error". Unlike the other classes, this appears to cause no harm because the standard never tests whether an object has [[Class]] "Error".)
Note that Function objects, Array objects, etc. are by definition not host objects.