FAQ Topic - What are object models? (2010-03-21)
in [JavaScript]
|
From: Richard Cornford on 24 Mar 2010 07:43 On Mar 24, 9:52 am, Thomas 'PointedEars' Lahn wrote: > Garrett Smith wrote: <snip> >> A host object may be implemented as a native object. > > No, absolutely not. I disagree with that. I have never seen any reason for a host object not being implemented as a native object (and with ES5 (getters and setters), and fast modern JS engines it would be quite a viable option) . Take the navigator - object -, is there a reason that a host (browser) environment could not execute a little javascript code during the initial loading of a web page that created that object as a normal javascript object, and appropriately populated its properties and methods? > | NOTE Any object that is not native is a host object. <snip> Didn't you already in this thread point out the characteristic of logic that means that while the above does say 'IF (NOT native) THEN (host object)', it does not validly imply 'IF (host object) THEN (NOT native)'. Richard.
From: Thomas 'PointedEars' Lahn on 24 Mar 2010 11:01 Richard Cornford wrote: > On Mar 24, 9:52 am, Thomas 'PointedEars' Lahn wrote: >> Garrett Smith wrote: >>> A host object may be implemented as a native object. >> No, absolutely not. > > I disagree with that. I have never seen any reason for a host object > not being implemented as a native object (and with ES5 (getters and > setters), and fast modern JS engines it would be quite a viable > option) . AISB, that an object behaves like a native object is not a sufficient criterion for it to be one. So there can be host objects that behave like native objects. If that is meant by "implemented as a native object", I agree; if not, then not. > Take the navigator - object -, is there a reason that a host > (browser) environment could not execute a little javascript code > during the initial loading of a web page that created that object as a > normal javascript object, and appropriately populated its properties > and methods? Good question. I will have to think about it. >> | NOTE Any object that is not native is a host object. > <snip> > > Didn't you already in this thread point out the characteristic of > logic that means that while the above does say 'IF (NOT native) THEN > (host object)', it does not validly imply 'IF (host object) THEN (NOT > native)'. Yes, I did not. I have pointed out: ,-<news:2014072.KRxA6XjA2N(a)PointedEars.de> | | The opposite of "fully defined by this specification" is "not fully | defined by this specification". It is not "not defined by this | specification (at all)". The NOTE above is a statement about sets of objects instead. The statement expands to: "Any object that is not [an object in an ECMAScript implementation whose semantics are fully defined by this specification rather than by the host environment] is [an object supplied by the host environment to complete the execution environment of ECMAScript]." The key word here being "fully". IIUC you are implying that the following statement would make sense: "A host object can be an object in an ECMAScript implementation whose semantics are fully defined by this specification rather than by the host environment and is an object supplied by the host environment to complete the execution environment of ECMAScript." IMHO that would be contradictory. Either the semantics of the object are *fully* defined by the ECMAScript Specification or the object is supplied by the host environment to *complete* the execution environment of ECMAScript. See also my set diagram. PointedEars -- Prototype.js was written by people who don't know javascript for people who don't know javascript. People who don't know javascript are not the best source of advice on designing systems that use javascript. -- Richard Cornford, cljs, <f806at$ail$1$8300dec7(a)news.demon.co.uk>
From: Richard Cornford on 24 Mar 2010 13:41 On Mar 24, 3:01 pm, Thomas 'PointedEars' Lahn wrote: > Richard Cornford wrote: >> On Mar 24, 9:52 am, Thomas 'PointedEars' Lahn wrote: >>> Garrett Smith wrote: >>>> A host object may be implemented as a native object. >>> No, absolutely not. > >> I disagree with that. I have never seen any reason for a host >> object not being implemented as a native object (and with ES5 >> (getters and setters), and fast modern JS engines it would be >> quite a viable option) . > > AISB, that an object behaves like a native object is not a > sufficient criterion for it to be one. Obviously, there is nothing to stop a non-native object from being indistinguishable from a native object. The freedom given to the host objects must encompass their behaving exactly like native objects if they want to. But that does not preclude the possibility of a host object being a native object. > So there can be host objects that behave like > native objects. But is there a reason for there not being host object that behave like native object because they are native objects? > If that is meant by "implemented as a native object", > I agree; if not, then not. What I mean be 'implemented as native objects' is having the host use javascript to create objects that it then exposes as part of its object model. >> Take the navigator - object -, is there a reason that a host >> (browser) environment could not execute a little javascript >> code during the initial loading of a web page that created >> that object as a normal javascript object, and appropriately >> populated its properties and methods? > > Good question. I will have to think about it. Another example, observing that the - appendChild - method is the equivalent of - insertBefore - when the second argument to the latter method is null, and given a host the exposes (and uses) the prototype of Node (which is pretty common these days), it would possible for a DOM environment to implement - insertBefore - in the normal way and then, prior to executing any other script, execute:- Node.prototype.appendChild = function(el){ this.insertBefore(el, null); }; Thus completing the W3C DOM Node interface by adding the otherwise missing - appendChild - method, using a native javascript function. The - appendChild - method would be a host method and so a host object (provided by the host, but facilitated by the ECMAScript implementation). >>> | NOTE Any object that is not native is a host object. >> <snip> > >> Didn't you already in this thread point out the characteristic >> of logic that means that while the above does say 'IF (NOT native) >> THEN (host object)', it does not validly imply 'IF (host object) >> THEN (NOT native)'. > > Yes, I did not. I have pointed out: > > ,-<news:2014072.KRxA6XjA2N(a)PointedEars.de> > | > | The opposite of "fully defined by this specification" is "not > | fully defined by this specification". It is not "not defined > | by this specification (at all)". > > The NOTE above is a statement about sets of objects instead. The > statement expands to: > > "Any object that is not [an object in an ECMAScript implementation > whose semantics are fully defined by this specification rather than > by the host environment] is [an object supplied by the host > environment to complete the execution environment of ECMAScript]." That comes across as a bit pointless as NOT "rather than by the host environment" is then "by the host environment", which rather goes without saying. > The key word here being "fully". Then the "rather than by the host environment" but probably shouldn't have been there. > IIUC you are implying that the following statement would make sense: > > "A host object can be an object in an ECMAScript implementation No. The whole point of host objects is that they are not provided by an ECMAScript implementation, and so could never be described as being "in an ECMAScript implementation". It would be better to say "in an ECMAScript environment" or "in an environment in which ECMAScript executes". > whose semantics are fully defined by this specification rather > than by the host environment and is an object supplied by the host > environment to complete the execution environment of ECMAScript." > > IMHO that would be contradictory. It should be possible for a host environment to directly employ an ECMAScript implementation to create objects that it then supplies to complete the execution environment, and then those object's behaviour would be fully defined by the ECMAScript standard. > Either the semantics of the object are > *fully* defined by the ECMAScript Specification or the object is > supplied by the host environment to *complete* the execution > environment of ECMAScript. You are hanging that on the word "semantics", which is relating to meaning. An object created in the course of executing an ECMAScript program doesn't have its meaning defined in the standard, it has its behaviour defined there, yet it is a native object. > See also my set diagram. I think your diagram is wrong. I still see no reason why the set of host objects cannot cross the boundary between the set of native objects and the set of non-native object (even if all the non-native objects have to be in the set of host object). I think your diagram is wrong. I still see no reason why the set of host objects cannot be the set of all non-native objects plus zero or more native objects that are brought into existence by the host (using the ECMAScript implementation). JavaScript(tm) and JScript can both be executed in various hosts. Some things are common to all resulting environments and some things are only found in some of those environments. Given that a host object is provided by the host, anything that is not found in all hosts that can support any single ECMAScript implementation must be a host object, and the things that are common will mostly be non-host (except those that are common by coincidence, such as the ActiveXObject constructor that is found in IE and WSH). Richard.
From: Thomas 'PointedEars' Lahn on 24 Mar 2010 15:46 Richard Cornford wrote: > On Mar 24, 3:01 pm, Thomas 'PointedEars' Lahn wrote: >> Richard Cornford wrote: >>> On Mar 24, 9:52 am, Thomas 'PointedEars' Lahn wrote: >>>> | NOTE Any object that is not native is a host object. >>> [...] >> >> The NOTE above is a statement about sets of objects instead. The >> statement expands to: >> >> "Any object that is not [an object in an ECMAScript implementation ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> whose semantics are fully defined by this specification rather than >> by the host environment] is [an object supplied by the host >> environment to complete the execution environment of ECMAScript]." > > [...] >> IIUC you are implying that the following statement would make sense: >> >> "A host object can be an object in an ECMAScript implementation [...] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > No. The whole point of host objects is that they are not provided by > an ECMAScript implementation, and so could never be described as being > "in an ECMAScript implementation". Very good. However, as you can see above, I have only applied the existing definitions in ECMAScript Edition 5 *verbatim* to your assumption that a host object could be a native one. As the union of the set of facts and the assumption creates a contradiction, the assumption must be false. q.e.d. PointedEars -- Danny Goodman's books are out of date and teach practices that are positively harmful for cross-browser scripting. -- Richard Cornford, cljs, <cife6q$253$1$8300dec7(a)news.demon.co.uk> (2004)
From: Garrett Smith on 24 Mar 2010 17:13
Thomas 'PointedEars' Lahn wrote: > Richard Cornford wrote: > >> On Mar 24, 3:01 pm, Thomas 'PointedEars' Lahn wrote: >>> Richard Cornford wrote: >>>> On Mar 24, 9:52 am, Thomas 'PointedEars' Lahn wrote: [...] >>> IIUC you are implying that the following statement would make sense: >>> >>> "A host object can be an object in an ECMAScript implementation [...] > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> No. The whole point of host objects is that they are not provided by >> an ECMAScript implementation, and so could never be described as being >> "in an ECMAScript implementation". > > Very good. However, as you can see above, I have only applied the existing > definitions in ECMAScript Edition 5 *verbatim* to your assumption that a > host object could be a native one. > The specification does not forbid the host environment from implementing host objects as native objects. That is a fact, not an assumption. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/ |