Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #22917

Re: JavaScript unfairly blamed?

Show all headers | View raw

Christoph Michael Becker wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Christoph Michael Becker wrote:
>>> Of course.  However, the DOM could have specified that for every
>>> interface there has to be an according class (or a respective construct
>>> according to the implementing language, such as a constructor function
>>> for ECMAScript implementations) with the same name which implements the
>>> interface.
>> 
>> That would have changed it from being a language-neutral API into being a
>> language-dependent one, at least.
> 
> ACK.  There could, however, (have) be(en) (an) additional
> specification(s) for ECMAScript (and maybe others for other languages),
> which go beyond the DOM specification.  Being able to reliably augment
> DOM objects would be desirable at least for some cases, such as defining
> certain methods for backward compatibility
> (Element.getElementsByClassName() comes to mind).  Without this ability
> one has to define methods in somewhat unrelated objects passing the
> target object as parameter (not as nice to read, IMO), or to wrap the
> DOM "completely" (not as efficient).

In <news:52eae8e5$0$6558$9b4e6d93@newsspool4.arcor-online.net> you called 
those “a reasonable solution, IMHO.”  You will have decide how your argument 
goes :)

IMCO they *are* that.  It becomes even better if you consider that methods 
can be devised that forward modifications and read-access to the properties 
of the encapsulated DOM object; see JSX:widgets.js [0].  (The same way 
methods calls could be forwarded; I have not done that yet.  [And then there 
are ES6 Proxy instances.])
 
> Of course, for histonric reasons these workarounds are necessary anyway
> today, but that could change sometime.

I find that highly unlikely, and this is why:

Would I want to augment host objects themselves instead?  If you think it 
through: probably not.  Because *I have no control* over the host 
environment that my code will be exposed to, and the "crazy" ideas of DOM 
implementors.  Every time I would have to check whether the object already 
had such a property or inherited one.  And I would have to test excessively  
and read *a lot* of documentation in order to make sure I am not  
accidentally writing to an existing property that has specific meaning in a 
particular host environment.  Because, AISB, interfaces define a minimum 
set of properties for the object implementing it [1]; implementing DOM 
interfaces still allows host objects that implement them to have *other* 
properties, even undocumented ones, in full compliance with the respective 
DOM specifications.  IOW, if I would attempt to augment host objects,
I would not only do something that the ECMAScript Specifications (all 
Editions) indicate, and that I know from experience, is error-prone [2];
I would also limit myself to known host environments.

Augmenting an object that is in the prototype chain of a host object is 
just as bad.  Because I cannot be certain that the properties I augment it 
with, if I can do that, have any effect.  If the implementors decided in 
their wisdom that the host object has a property of the same name, or 
inherited one from an object that is *before* the object I augmented in the 
prototype chain, my augmentation will be rendered ineffective. [3]  And even 
if I should be so lucky that my augmentation would be effective, do I really 
want to have *all* host objects inheriting from this object to have that 
property?  Probably not.

Finally, there is the scope chain augmentation, rooted in history, to  
consider.  A good example is the boolean “translate” property that element 
objects have in Chromium WebCore by default and that caused other people and 
me problems with our global “translate” function because the latter was not 
called. [4]  It turns out that the element object is in the scope chain of 
its event-handler attribute code. [5]  And it goes without saying that the 
interface-turned-class-defined prototype of the element object is in the 
prototype chain of the element object.  As a result, if you augment the 
prototype of an element object, you need to take care that none of the new 
properties, assuming they become effective, interfere with other code whose 
symbols are further up in the scope chain.  It is hard enough to avoid those 
that are already there.  And at least as long as Brendan Eich is alive (may 
he live long and prosper, despite our differences regarding the DOM), scope 
chain augmentation is not going to go away. [6]

I presume these are the real reasons why DOM object’s prototypes are 
scarcely augmented in the wild, if at all.  At least, why it is not an 
ubiquitous feature in DOM implementations.

__________
[0] <http://pointedears.de/wsvn/JSX/trunk/dom/widgets.js>
[1] 
<http://en.wikipedia.org/wiki/Application_programming_interface#API_in_object-oriented_languages>
[2] <http://ecma-international.org/ecma-262/5.1/#sec-8.6.2>
[3] <http://ecma-international.org/ecma-262/5.1/#sec-4.2.1>
[4] <http://stackoverflow.com/a/16046051/855543>
    (and no, it is _not_ a reserved word)
[5] <http://stackoverflow.com/questions/9158238/why-js-function-name-conflicts-with-element-id/9160009#9160009>
[6] <https://twitter.com/PointedEars2/status/404987315061149696> pp.
-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

Back to comp.lang.javascript | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: JavaScript unfairly blamed? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2014-01-26 02:37 -0800
  Re: JavaScript unfairly blamed? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-01-26 11:52 +0100
    Re: JavaScript unfairly blamed? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2014-01-26 12:04 -0800
      Re: JavaScript unfairly blamed? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-01-26 22:24 +0100
        Re: JavaScript unfairly blamed? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2014-01-26 14:49 -0800
          Re: JavaScript unfairly blamed? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-01-27 02:14 +0100
            Re: JavaScript unfairly blamed? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2014-01-27 18:30 -0800
              Re: JavaScript unfairly blamed? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-01-28 19:08 +0100
                Re: JavaScript unfairly blamed? Christoph Michael Becker <cmbecker69@arcor.de> - 2014-01-28 19:50 +0100
                Re: JavaScript unfairly blamed? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-01-28 21:18 +0100
                Re: JavaScript unfairly blamed? Christoph Michael Becker <cmbecker69@arcor.de> - 2014-01-28 22:27 +0100
                Re: JavaScript unfairly blamed? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-01-28 23:23 +0100
                Re: JavaScript unfairly blamed? Christoph Michael Becker <cmbecker69@arcor.de> - 2014-01-29 17:12 +0100
                Re: JavaScript unfairly blamed? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-01-31 22:30 +0100
                Re: JavaScript unfairly blamed? Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-01 22:35 +0100
                Re: JavaScript unfairly blamed? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2014-01-28 19:59 -0800
                Re: JavaScript unfairly blamed? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-01-31 14:08 +0100
                Re: JavaScript unfairly blamed? Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-01 22:52 +0100
                Re: JavaScript unfairly blamed? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2014-02-02 10:09 -0800
                Re: JavaScript unfairly blamed? Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-04 23:42 +0100
                Re: JavaScript unfairly blamed? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2014-01-28 19:40 -0800
                Re: JavaScript unfairly blamed? Christoph Michael Becker <cmbecker69@arcor.de> - 2014-01-29 17:17 +0100
                Re: JavaScript unfairly blamed? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2014-01-29 16:51 -0800
                Re: JavaScript unfairly blamed? Christoph Michael Becker <cmbecker69@arcor.de> - 2014-01-31 01:06 +0100
                Re: JavaScript unfairly blamed? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2014-01-28 19:36 -0800
                Re: JavaScript unfairly blamed? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-01-31 14:47 +0100
      Re: JavaScript unfairly blamed? John Harris <niam@jghnorth.org.uk.invalid> - 2014-01-27 14:36 +0000
        Re: JavaScript unfairly blamed? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2014-01-27 16:05 -0800
          Re: JavaScript unfairly blamed? John Harris <niam@jghnorth.org.uk.invalid> - 2014-01-29 15:26 +0000
            Re: JavaScript unfairly blamed? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2014-01-29 16:44 -0800
              "impedance mismatch", was: Re: JavaScript unfairly blamed? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-01-30 11:10 +0100
                Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? Tim Streater <timstreater@greenbee.net> - 2014-01-30 10:38 +0000
                Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-01-30 13:30 +0100
                Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? Denis McMahon <denismfmcmahon@gmail.com> - 2014-01-30 12:45 +0000
                Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-01-30 14:05 +0100
                Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? Dr J R Stockton <reply1400@merlyn.demon.co.uk.invalid> - 2014-01-31 21:32 +0000
                OT: "impedance mismatch" (was: "impedance mismatch", was: Re: JavaScript unfairly blamed?) Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-01 01:15 +0100
                Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? Denis McMahon <denismfmcmahon@gmail.com> - 2014-02-01 02:40 +0000
                Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-02-01 10:02 +0100
                Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-02-01 09:54 +0100
                Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? Denis McMahon <denismfmcmahon@gmail.com> - 2014-01-30 11:06 +0000
                Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-01-30 14:02 +0100
                Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? "ViLco" <villiber@tin.it> - 2014-01-30 16:24 +0100
                Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? Denis McMahon <denismfmcmahon@gmail.com> - 2014-01-31 00:35 +0000
                Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-01-31 11:16 +0100
                Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2014-01-30 15:14 -0800
                Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-01-31 00:56 +0100
                Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2014-01-30 22:13 -0800
                Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-01-31 11:51 +0100
                Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? Dr J R Stockton <J.R.Stockton@physics.org> - 2014-01-31 19:58 +0000
                Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-02-01 09:30 +0100
                Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? Dr J R Stockton <reply1400@merlyn.demon.co.uk.invalid> - 2014-02-02 17:44 +0000
                Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-02-03 01:15 +0100
                Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? John Harris <niam@jghnorth.org.uk.invalid> - 2014-02-03 14:58 +0000
                Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? Tim Streater <timstreater@greenbee.net> - 2014-02-03 15:36 +0000
                Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-02-03 17:59 +0100
                Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? Tim Streater <timstreater@greenbee.net> - 2014-02-03 17:18 +0000
                Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-02-03 19:47 +0100
                Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? John Harris <niam@jghnorth.org.uk.invalid> - 2014-02-04 10:33 +0000
                Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-02-06 13:40 +0100
                Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? Dr J R Stockton <reply1400@merlyn.demon.co.uk.invalid> - 2014-02-06 10:12 +0000
                Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-02-07 10:32 +0100
                Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? Dr J R Stockton <reply1400@merlyn.demon.co.uk.invalid> - 2014-02-08 23:06 +0000
                Re: "impedance mismatch", was: Re: JavaScript unfairly blamed? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-02-09 10:33 +0100

csiph-web