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

Groups > comp.lang.javascript > #22794 > unrolled thread

Re: JavaScript unfairly blamed?

Back to article view | Back to comp.lang.javascript

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  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

Page 1 of 4  [1] 2 3 4  Next page →

#22794 — Re: JavaScript unfairly blamed?

On Sunday, January 26, 2014 2:15:45 AM UTC-6, Stefan Ram wrote:
> Douglas Crockford wrote:
> 
> |The API Of the browser, the Document Object Model (DOM) is
> |quite awful, and JavaScript is unfairly blamed.
> 
>   What's so awful about the DOM?

Note that since that was written, much has changed, but traditionally the issues have been, but not limited to:

1. Verbosity
2. Inconsistent implementation
3. non-idiomatic usage
4. Slower than equivalent JavaScript code
5. A lack of necessary APIs

[toc] | [next] | [standalone]

#22795

Michael Haufe (TNO) wrote:

> Stefan Ram wrote:
>> Douglas Crockford wrote:
>> 
>> |The API Of the browser, the Document Object Model (DOM) is
>> |quite awful, and JavaScript is unfairly blamed.
>> 
>>   What's so awful about the DOM?
> 
> Note that since that was written, much has changed, but traditionally the
> issues have been, but not limited to:
> 
> 1. Verbosity

Most of the time, though, that “verbosity” contributes to its clarity, 
efficiency, and robustness.  The other extreme being jQuery, which is terse 
when used, but ambiguous, inefficient, and unreliable.  I prefer the DOM 
over jQuery anytime.

> 2. Inconsistent implementation

You can blame the implementors of the API for that, not the API.

> 3. non-idiomatic usage

Such as?

> 4. Slower than equivalent JavaScript code

Given that pure JavaScript has no way to access documents, what is that code 
you are talking about?

> 5. A lack of necessary APIs

As the DOM *is* an API, you must mean its (API) _features_.  Such as?

-- 
PointedEars

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

[toc] | [prev] | [next] | [standalone]

#22807

Thomas 'PointedEars' Lahn wrote:
> Michael Haufe (TNO) wrote:
[...]
 
> > 1. Verbosity
> 
> Most of the time, though, that “verbosity” contributes to its clarity, 
> efficiency, and robustness.  The other extreme being jQuery, which is terse 
> when used, but ambiguous, inefficient, and unreliable.  I prefer the DOM 
> over jQuery anytime.

Long-windedness vs. cultural code-golf indeed
 
> > 2. Inconsistent implementation
> 
> You can blame the implementors of the API for that, not the API.

Yes, but it is one of the common complaints one hears.

> > 4. Slower than equivalent JavaScript code
> 
> Given that pure JavaScript has no way to access documents, what is that code 
> you are talking about?

The issue with the DOM forcing you into Immediate Mode whereas a
Retained Mode is more appropriate in many situations. Hence the
are countless articles on how avoid repaint/reflow through 
manipulation of JavaScript objects creating a facsimile of the
document and/or divorced fragments which are then "committed" for
display after manipulation. If a web dev's bag of tricks contains
a bullet point about "avoid the DOM", then that is a smell if I
ever smelled one.

Also, doing for example BFS(myJSObjectDomFacsimile) is faster than
BFS(someDomElementUsingElementMemberMethods) as you are already
aware due to the numerous calls to an element's methods vs 
reference walking in the first

> > 5. A lack of necessary APIs
> 
> As the DOM *is* an API, you must mean its (API) _features_.  Such as?

As listed here: <http://www.w3.org/2009/dap/>

> > 3. non-idiomatic usage
> 
> Such as?

While the other points are a repeat of arguments I've seen/heard,
this particular point is my opinion. The DOM is a leaky paradigm
that wants an Object-Oriented, imperative use. Since JavaScript
is not strongly in those camps, there are impedance mismatches that
occur, and it is common IME that code tends to get warped to fit this
API (or it grows overcomplicated wrappers in libs and frameworks).
This is another smell of bad design.

[toc] | [prev] | [next] | [standalone]

#22808

Michael Haufe (TNO) wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Michael Haufe (TNO) wrote:
> [...]
>> > 4. Slower than equivalent JavaScript code
>> 
>> Given that pure JavaScript has no way to access documents, what is that
>> code you are talking about?
> 
> The issue with the DOM forcing you into Immediate Mode whereas a
                                          ^^^^^^^^^^^^^^
> Retained Mode is more appropriate in many situations.
  ^^^^^^^^^^^^^
I am not aware of the DOM forcing me into anything.  Please define those 
terms you just invented.

> Hence the are countless articles on how avoid repaint/reflow through
> manipulation of JavaScript objects creating a facsimile of the
> document and/or divorced fragments which are then "committed" for
> display after manipulation.

It appears to be easy to avoid repaint/reflow: First build the subtree in 
memory, then append it.  Which facsimiles are you talking about?  Please 
elaborate.

> If a web dev's bag of tricks contains a bullet point about "avoid the
> DOM", then that is a smell if I ever smelled one.

I am not sure that this even is an argument, let alone a sound one.
 
> Also, doing for example BFS(myJSObjectDomFacsimile) is faster than
                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^
> BFS(someDomElementUsingElementMemberMethods) as you are already
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> aware due to the numerous calls to an element's methods vs
> reference walking in the first

Please elaborate.
 
>> > 5. A lack of necessary APIs
>> 
>> As the DOM *is* an API, you must mean its (API) _features_.  Such as?
> 
> As listed here: <http://www.w3.org/2009/dap/>

How does this status document substantiate your argument?
 
>> > 3. non-idiomatic usage
>> 
>> Such as?
> 
> While the other points are a repeat of arguments I've seen/heard,
> this particular point is my opinion. The DOM is a leaky paradigm
                                                    ^^^^^^^^^^^^^^
> that wants an Object-Oriented, imperative use. Since JavaScript
> is not strongly in those camps,

Am I to understand that you think JavaScript is not strong with regard to 
object-oriented, imperative use?  If yes, how did you get that idea?  With 
regard to programming paradigms, JavaScript is an object-oriented, 
procedural-imperative programming language, is it not?

> there are impedance mismatches that occur, and it is common IME that code
            ^^^^^^^^^^^^^^^^^^^^
> tends to get warped to fit this API (or it grows overcomplicated wrappers
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> in libs and frameworks).  This is another smell of bad design.

Have you been spending too much time with the ties?  Your arguments read 
like a winner’s game of Bullshit Bingo: You write much, but your words mean 
nothing.  Please define your terminology (better: avoid it in the future) 
and elaborate on your arguments.

-- 
PointedEars

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

[toc] | [prev] | [next] | [standalone]

#22809

On Sunday, January 26, 2014 3:24:47 PM UTC-6, Thomas 'PointedEars' Lahn wrote:
> Michael Haufe (TNO) wrote:

> > The issue with the DOM forcing you into Immediate Mode whereas a
>                                           ^^^^^^^^^^^^^^
> > Retained Mode is more appropriate in many situations.
>   ^^^^^^^^^^^^^
> I am not aware of the DOM forcing me into anything.  Please define those 
> terms you just invented.

If you think I just invented the terms, I'm disappointed.

> > Hence the are countless articles on how avoid repaint/reflow through
> > manipulation of JavaScript objects creating a facsimile of the
> > document and/or divorced fragments which are then "committed" for
> > display after manipulation.
> 
> It appears to be easy to avoid repaint/reflow: First build the subtree in 
> memory, then append it.

I wouldn't claim "easy" if there are numerous articles on it

> Which facsimiles are you talking about?

You already have it in mind, the details are on how this happens to be accomplished.

> Please elaborate.

I don't think I should bother as I suspect you are more interested in having an argument itself than arriving at a conclusion. I'm definitely not in the mood for such a waste of time.

> > If a web dev's bag of tricks contains a bullet point about "avoid the
> > DOM", then that is a smell if I ever smelled one.
> 
> I am not sure that this even is an argument, let alone a sound one.

Regardless of your opinion of it, it is a common claim and practice.

> > Also, doing for example BFS(myJSObjectDomFacsimile) is faster than
>                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > BFS(someDomElementUsingElementMemberMethods) as you are already
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > aware due to the numerous calls to an element's methods vs
> > reference walking in the first
>
> Please elaborate.

I've elaborated enough.

> >> > 5. A lack of necessary APIs
> >> 
> >> As the DOM *is* an API, you must mean its (API) _features_.  Such as?
> > 
> > As listed here: <http://www.w3.org/2009/dap/>
> 
> How does this status document substantiate your argument?

The fact that there is effort in creating new APIs demonstrates that what has traditionally been provided is insufficient, and yes: API is being used in plural.
 
> >> > 3. non-idiomatic usage
> >> 
> >> Such as?
> > 
> > While the other points are a repeat of arguments I've seen/heard,
> > this particular point is my opinion. The DOM is a leaky paradigm
>                                                     ^^^^^^^^^^^^^^
> > that wants an Object-Oriented, imperative use. Since JavaScript
> > is not strongly in those camps,
> 
> Am I to understand that you think JavaScript is not strong with regard to 
> object-oriented, imperative use?  If yes, how did you get that idea?  With 
> regard to programming paradigms, JavaScript is an object-oriented, 
> procedural-imperative programming language, is it not?

I'm referring to the fact it isn't _ONLY_ that paradigm (I used the qualifier "strongly" for a reason). Stop trying to be contrary for its own sake.
 
> > there are impedance mismatches that occur, and it is common IME that code
>             ^^^^^^^^^^^^^^^^^^^^
> > tends to get warped to fit this API (or it grows overcomplicated wrappers
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > in libs and frameworks).  This is another smell of bad design.
 
> Have you been spending too much time with the ties?  Your arguments read 
> like a winner’s game of Bullshit Bingo: You write much, but your words mean 
> nothing.  Please define your terminology (better: avoid it in the future) 
> and elaborate on your arguments.

I'm not in the business of helping you with reading comprehension if you're unwilling to even glance at the well-defined terminology you don't know. It seems to me you have an ulterior motive here and I'm not interested in it. (No, I won't define "ulterior" for you...)

[toc] | [prev] | [next] | [standalone]

#22810

Michael Haufe (TNO) wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Michael Haufe (TNO) wrote:
>> > The issue with the DOM forcing you into Immediate Mode whereas a
>>                                           ^^^^^^^^^^^^^^
>> > Retained Mode is more appropriate in many situations.
>>   ^^^^^^^^^^^^^
>> I am not aware of the DOM forcing me into anything.  Please define those
>> terms you just invented.
> 
> If you think I just invented the terms, I'm disappointed.
> 
>> > Hence the are countless articles on how avoid repaint/reflow through
>> > manipulation of JavaScript objects creating a facsimile of the
>> > document and/or divorced fragments which are then "committed" for
>> > display after manipulation.
>> 
>> It appears to be easy to avoid repaint/reflow: First build the subtree in
>> memory, then append it.
> 
> I wouldn't claim "easy" if there are numerous articles on it

The number of articles on a subject is not sufficient evidence of anything 
regarding the subject, but of the need of their authors to express 
themselves.

>> Which facsimiles are you talking about?
> 
> You already have it in mind,

Oh, you can read my mind now?  I am impressed :->

> the details are on how this happens to be accomplished.
> 
>> Please elaborate.
> 
> I don't think I should bother as I suspect you are more interested in
> having an argument itself than arriving at a conclusion. I'm definitely
> not in the mood for such a waste of time.

I think if you had any sound arguments instead of just buzzwords seemingly 
randomly strewn on top of your arguments, you would at least try to answer 
my questions and requests instead of falling back on the /ad hominem/ 
argument.  So you do not appear to be at least in the right mood *for a 
constructive discussion*, which is unfortunate.
 
>> >> > 5. A lack of necessary APIs
>> >> As the DOM *is* an API, you must mean its (API) _features_.  Such as?
>> > As listed here: <http://www.w3.org/2009/dap/>
>> How does this status document substantiate your argument?
> 
> The fact that there is effort in creating new APIs demonstrates that what
> has traditionally been provided is insufficient, and yes: API is being
> used in plural.

Your logic is flawed.  The fact that new APIs are being built on the core 
DOM right now is neither indication nor evidence that it is or has been 
lacking necessary APIs; but that it is flexible enough to allow them now 
that technology has evolved enough so that they are considered necessary.
  
>> >> > 3. non-idiomatic usage
>> >> 
>> >> Such as?
>> > 
>> > While the other points are a repeat of arguments I've seen/heard,
>> > this particular point is my opinion. The DOM is a leaky paradigm
>>                                                     ^^^^^^^^^^^^^^
>> > that wants an Object-Oriented, imperative use. Since JavaScript
>> > is not strongly in those camps,
>> 
>> Am I to understand that you think JavaScript is not strong with regard to
>> object-oriented, imperative use?  If yes, how did you get that idea? 
>> With regard to programming paradigms, JavaScript is an object-oriented,
>> procedural-imperative programming language, is it not?
> 
> I'm referring to the fact it isn't _ONLY_ that paradigm (I used the
> qualifier "strongly" for a reason).

ACK.  I was not familiar with the expression and had assumed that this was 
some sort of typo.

> Stop trying to be contrary for its own sake.

You do know that English is not my native language, don't you?

Anyhow, even with your clarification I cannot find yours to be a sound 
argument.  Yes, JavaScript™ and all other ECMAScript implementations support 
the procedural-imperative, the object-oriented, and the functional 
programming paradigms.  Obviously it supports the paradigm that is suggested 
(but not required) by the W3C DOM.  How does that make it/them less suitable 
for using its features?

ISTM you have it backwards.  All current DOM implementations *originate* 
from JavaScript™ (versions 1.0 through 1.3), through the W3C DOM; not vice-
versa.  And there are ECMAScript Language Bindings *specified* for W3C DOM 
interfaces.

-- 
PointedEars

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

[toc] | [prev] | [next] | [standalone]

#22834

Thomas 'PointedEars' Lahn wrote:
> The number of articles on a subject is not sufficient evidence of anything
> regarding the subject, but of the need of their authors to express
> themselves.

I would consider it reasonable to see it as suggestive of the problem. 

> Oh, you can read my mind now?  I am impressed :->

You've expressed yourself often enough over the years to be predictable in
some regards

>  I think if you had any sound arguments instead of just buzzwords seemingly
>  randomly strewn on top of your arguments, you would at least try to answer
>  my questions and requests instead of falling back on the /ad hominem/
>  argument.  So you do not appear to be at least in the right mood *for a
>  constructive discussion*, which is unfortunate.

I might want more than an abstract request then, and confidence that there
would indeed be something constructive.

> Your logic is flawed.  The fact that new APIs are being built on the core
> DOM right now is neither indication nor evidence that it is or has been
> lacking necessary APIs; but that it is flexible enough to allow them now
> that technology has evolved enough so that they are considered necessary.

Are you seriously trying to claim accident over evolutionary pressure?

Michael Haufe wrote:
> I'm referring to the fact it isn't _ONLY_ that paradigm (I used the
> qualifier "strongly" for a reason).

Thomas 'PointedEars' Lahn wrote:
> ACK.  I was not familiar with the expression and had assumed that this was
> some sort of typo.

Michael Haufe wrote:
> Stop trying to be contrary for its own sake.

Thomas 'PointedEars' Lahn wrote:
> You do know that English is not my native language, don't you?

Yes, what's your point?

Thomas 'PointedEars' Lahn wrote:
> Anyhow, even with your clarification I cannot find yours to be a sound
> argument.  Yes, JavaScript™ and all other ECMAScript implementations support
> the procedural-imperative, the object-oriented, and the functional
> programming paradigms.  Obviously it supports the paradigm that is suggested
> (but not required) by the W3C DOM.  How does that make it/them less suitable
> for using its features?

> ISTM you have it backwards.  All current DOM implementations *originate*
> from JavaScript™ (versions 1.0 through 1.3), through the W3C DOM; not vice-
> versa.  And there are ECMAScript Language Bindings *specified* for W3C DOM
> interfaces.

Regardless of what the origin was, the evolution has been divergent (though
there has been efforts to improve this lately). The very fact that the
term "interface" is used should be enough of a starting clue of the
mismatch.  Have the old arguments and discussions been forgotten/overlooked?
Is this mismatch honestly news here? Even an off-the-cuff search will yield
examples and arguments not yet mentioned: 

<http://channel9.msdn.com/Blogs/Charles/SPLASH-2011-Dave-Thomas-On-Modern-Application-Development#time=12m14s>

<http://perfectionkills.com/whats-wrong-with-extending-the-dom/#what_went_wrong>

<http://www.artima.com/intv/domP.html>

...and plenty of others if one is interested enough to bother looking. Break out the bubble pl0x. The insularity is chafing

[toc] | [prev] | [next] | [standalone]

#22851

Michael Haufe (TNO) wrote:

> [fallacies]
> 
> Thomas 'PointedEars' Lahn wrote:
>> Anyhow, even with your clarification I cannot find yours to be a sound
>> argument.  Yes, JavaScript™ and all other ECMAScript implementations
>> support the procedural-imperative, the object-oriented, and the
>> functional programming paradigms.  Obviously it supports the paradigm
>> that is suggested (but not required) by the W3C DOM.  How does that make
>> it/them less suitable for using its features?
> 
>> ISTM you have it backwards.  All current DOM implementations *originate*
>> from JavaScript™ (versions 1.0 through 1.3), through the W3C DOM; not
>> vice-versa.  And there are ECMAScript Language Bindings *specified* for
>> W3C DOM interfaces.
> 
> Regardless of what the origin was, the evolution has been divergent
                                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> (though there has been efforts to improve this lately).
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
What are you talking about?

> The very fact that the term "interface" is used should be enough of a
> starting clue of the mismatch.

Again, why? 

1. DOMs are specified using *interfaces* that are to be *implemented*.

2. Interfaces are a concept of, and are intended for use in,
   *object-oriented programming languages*.

3. ECMAScript *implementations* *are* object-oriented programming languages.

Where is the mismatch?

> Have the old arguments and discussions been
> forgotten/overlooked? Is this mismatch honestly news here? Even an
> off-the-cuff search will yield examples and arguments not yet mentioned:
> 
> <http://channel9.msdn.com/Blogs/Charles/SPLASH-2011-Dave-Thomas-On-Modern-Application-Development#time=12m14s>
> 
> <http://perfectionkills.com/whats-wrong-with-extending-the-dom/#what_went_wrong>
> 
> <http://www.artima.com/intv/domP.html>

Throwing a bunch of URIs at people is no substitute for a sound argument.
 
> ...and plenty of others if one is interested enough to bother looking.
> Break out the bubble pl0x. The insularity is chafing
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Here we go again.

-- 
PointedEars

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

[toc] | [prev] | [next] | [standalone]

#22853

Thomas 'PointedEars' Lahn wrote:

> Michael Haufe (TNO) wrote:
> 
>> [fallacies]
>>
>> Thomas 'PointedEars' Lahn wrote:
>>> Anyhow, even with your clarification I cannot find yours to be a sound
>>> argument.  Yes, JavaScript™ and all other ECMAScript implementations
>>> support the procedural-imperative, the object-oriented, and the
>>> functional programming paradigms.  Obviously it supports the paradigm
>>> that is suggested (but not required) by the W3C DOM.  How does that make
>>> it/them less suitable for using its features?
>>
>>> ISTM you have it backwards.  All current DOM implementations *originate*
>>> from JavaScript™ (versions 1.0 through 1.3), through the W3C DOM; not
>>> vice-versa.  And there are ECMAScript Language Bindings *specified* for
>>> W3C DOM interfaces.
>>
>> Regardless of what the origin was, the evolution has been divergent
>                                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> (though there has been efforts to improve this lately).
>           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> What are you talking about?
> 
>> The very fact that the term "interface" is used should be enough of a
>> starting clue of the mismatch.
> 
> Again, why? 
> 
> 1. DOMs are specified using *interfaces* that are to be *implemented*.
> 
> 2. Interfaces are a concept of, and are intended for use in,
>    *object-oriented programming languages*.
> 
> 3. ECMAScript *implementations* *are* object-oriented programming languages.
> 
> Where is the mismatch?
> 
>> Have the old arguments and discussions been
>> forgotten/overlooked? Is this mismatch honestly news here? Even an
>> off-the-cuff search will yield examples and arguments not yet mentioned:
>>
>> <http://channel9.msdn.com/Blogs/Charles/SPLASH-2011-Dave-Thomas-On-Modern-Application-Development#time=12m14s>
>>
>> <http://perfectionkills.com/whats-wrong-with-extending-the-dom/#what_went_wrong>
>>
>> <http://www.artima.com/intv/domP.html>
> 
> Throwing a bunch of URIs at people is no substitute for a sound argument.

I believe at least one of the arguments Michael has made, is that the
DOM defines interfaces, but not actual objects ("classes"), which can be
extended.  While a particular DOM implementation might expose an Element
object, for instance, this is not mandatory.  For that reason alone it
is not possible to reliably extend DOM objects (let alone the problem
that they are host objects, and ECMAScript leaves broad room for the
actual behavior of these), what may be regarded as (impedance) mismatch.

Apparently, many programmers desire the ability to extend the DOM, and
so use libraries which simulate this feature, such as jQuery.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#22859

Christoph Michael Becker wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Michael Haufe (TNO) wrote:
>>> [fallacies]
>>>
>>> Thomas 'PointedEars' Lahn wrote:
>>>> Anyhow, even with your clarification I cannot find yours to be a sound
>>>> argument.  Yes, JavaScript™ and all other ECMAScript implementations
>>>> support the procedural-imperative, the object-oriented, and the
>>>> functional programming paradigms.  Obviously it supports the paradigm
>>>> that is suggested (but not required) by the W3C DOM.  How does that
>>>> make it/them less suitable for using its features?
>>>
>>>> ISTM you have it backwards.  All current DOM implementations
>>>> *originate* from JavaScript™ (versions 1.0 through 1.3), through the
>>>> W3C DOM; not
>>>> vice-versa.  And there are ECMAScript Language Bindings *specified* for
>>>> W3C DOM interfaces.
>>>
>>> Regardless of what the origin was, the evolution has been divergent
>>                                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> (though there has been efforts to improve this lately).
>>           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> What are you talking about?
>> 
>>> The very fact that the term "interface" is used should be enough of a
>>> starting clue of the mismatch.
>> 
>> Again, why?
>> 
>> 1. DOMs are specified using *interfaces* that are to be *implemented*.
>> 
>> 2. Interfaces are a concept of, and are intended for use in,
>>    *object-oriented programming languages*.
>> 
>> 3. ECMAScript *implementations* *are* object-oriented programming
>> languages.
>> 
>> Where is the mismatch?
>> 
>>> Have the old arguments and discussions been
>>> forgotten/overlooked? Is this mismatch honestly news here? Even an
>>> off-the-cuff search will yield examples and arguments not yet mentioned:
>>>
>>> <http://channel9.msdn.com/Blogs/Charles/SPLASH-2011-Dave-Thomas-On-Modern-Application-Development#time=12m14s>
>>>
>>> <http://perfectionkills.com/whats-wrong-with-extending-the-dom/#what_went_wrong>
>>>
>>> <http://www.artima.com/intv/domP.html>
>> 
>> Throwing a bunch of URIs at people is no substitute for a sound argument.
> 
> I believe at least one of the arguments Michael has made, is that the
> DOM defines interfaces, but not actual objects ("classes"), which can be
> extended.  While a particular DOM implementation might expose an Element
> object, for instance, this is not mandatory.  For that reason alone it
> is not possible to reliably extend DOM objects (let alone the problem
> that they are host objects, and ECMAScript leaves broad room for the
> actual behavior of these), what may be regarded as (impedance) mismatch.

That would be a specious argument, then.  The very purpose, and the benefit, 
of an interface in OOP is that an object implementing it provides a well-
defined minimum set of properties and methods, whereas how the methods are 
implemented is left to the object, allowing for, but not requiring, 
polymorphism.  It is decidedly _not_ the purpose of an interface to be 
available itself as an object that can be extended; an interface is _not_ 
the same as a class.

So any mismatch between the DOMs and ECMAScript implementations, from which 
they are derived, exists only in the mind of the person arguing that an 
interface should allow the very thing that defeats its purpose.
 
> Apparently, many programmers desire the ability to extend the DOM, and
> so use libraries which simulate this feature, such as jQuery.

Non sequitur.
 
-- 
PointedEars

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

[toc] | [prev] | [next] | [standalone]

#22862

Thomas 'PointedEars' Lahn wrote:

> Christoph Michael Becker wrote:
> 
>> I believe at least one of the arguments Michael has made, is that the
>> DOM defines interfaces, but not actual objects ("classes"), which can be
>> extended.  While a particular DOM implementation might expose an Element
>> object, for instance, this is not mandatory.  For that reason alone it
>> is not possible to reliably extend DOM objects (let alone the problem
>> that they are host objects, and ECMAScript leaves broad room for the
>> actual behavior of these), what may be regarded as (impedance) mismatch.
> 
> That would be a specious argument, then.  The very purpose, and the benefit, 
> of an interface in OOP is that an object implementing it provides a well-
> defined minimum set of properties and methods, whereas how the methods are 
> implemented is left to the object, allowing for, but not requiring, 
> polymorphism.  It is decidedly _not_ the purpose of an interface to be 
> available itself as an object that can be extended; an interface is _not_ 
> the same as a class.

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.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#22864

Christoph Michael Becker wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Christoph Michael Becker wrote:
>>> I believe at least one of the arguments Michael has made, is that the
>>> DOM defines interfaces, but not actual objects ("classes"), which can be
>>> extended.  While a particular DOM implementation might expose an Element
>>> object, for instance, this is not mandatory.  For that reason alone it
>>> is not possible to reliably extend DOM objects (let alone the problem
>>> that they are host objects, and ECMAScript leaves broad room for the
>>> actual behavior of these), what may be regarded as (impedance) mismatch.
>> 
>> That would be a specious argument, then.  The very purpose, and the
>> benefit, of an interface in OOP is that an object implementing it
>> provides a well- defined minimum set of properties and methods, whereas
>> how the methods are implemented is left to the object, allowing for, but
>> not requiring, polymorphism.  It is decidedly _not_ the purpose of an
>> interface to be available itself as an object that can be extended; an
>> interface is _not_ the same as a class.
> 
> 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.  For example, DOM Level 3 Core specifies 
only a language binding for Java and ECMAScript, but keep in mind that the 
attributes, methods, and language bindings in the DOM Specifications are 
*inclusive*:

,-<http://www.w3.org/DOM/#what>
| 
| The Document Object Model is a platform- and language-neutral interface
| that will allow programs and scripts to dynamically access and update the
| content, structure and style of documents. […]

,-<http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/>
| 
| This specification defines the Document Object Model Core Level 3, a
| platform- and language-neutral interface that allows programs and scripts
| to dynamically access and update the content, structure and style of
| documents.
 
-- 
PointedEars

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

[toc] | [prev] | [next] | [standalone]

#22874

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

Of course, for histonric reasons these workarounds are necessary anyway
today, but that could change sometime.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#22917

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.

[toc] | [prev] | [next] | [standalone]

#22927

Thomas 'PointedEars' Lahn wrote:

> 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 :)

Well, I was not arguing that augmenting DOM objects should be done (if
possible) as a *general* technique.  (IMHO, it still would be good if it
were possible, in *some* cases, such as adding methods for
backward-compatibility.)  My main point for entering the discussion was
that I was rather unsatisfied with its course until then, especially the
lack of sound explanation of the arguments.  Being rather a newbie to
ECMAScript and the DOM I still have a hard time understanding all the
implications of the "prototypal" nature of the language, opposed to
"class-based" OO, where it is usually not even possible to augment all
instances of a class after it has been defined.  So I found Michael's
arguments (insofar as I could understand them) rather intriguing, and I
took the chance to learn more about why augmenting DOM objects may or
not may be a good idea.  I was lucky to succeed. :)  Thanks.

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

Indeed, I had such widgets in mind, when I called Michael's cheap
wrappers/decorators a reasonable solution.  Thanks for the confirmation.

>> 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:
>
> [Very comprehensive explanation why augmenting DOM objects is a bad
> idea.]

Thanks.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#22867

On Tuesday, January 28, 2014 2:18:47 PM UTC-6, Thomas 'PointedEars' Lahn wrote:
> Christoph Michael Becker wrote:
> 
> > I believe at least one of the arguments Michael has made, is that the
> > DOM defines interfaces, but not actual objects ("classes"), which can be
> > extended.  While a particular DOM implementation might expose an Element
> > object, for instance, this is not mandatory.  For that reason alone it
> > is not possible to reliably extend DOM objects (let alone the problem
> > that they are host objects, and ECMAScript leaves broad room for the
> > actual behavior of these), what may be regarded as (impedance) mismatch.
> 
> That would be a specious argument, then.  The very purpose, and the benefit, 
> of an interface in OOP is that an object implementing it provides a well-
> defined minimum set of properties and methods, [...]

..and yet it is not only a minimum is it? The implementations must be treated as maximums as well, which contrary to the idioms of the language. 

> [...] whereas how the methods are 
> implemented is left to the object, allowing for, but not requiring, 
> polymorphism.

There are at least five types of polymorphism, I assume you're referring to Ad-Hoc

> It is decidedly _not_ the purpose of an interface to be  
> available itself as an object that can be extended; an interface is _not_  the same as a class.

I know some SmallTalkers who would disagree, but I digress...

Yes, yes, an interface specifies intent. This is well known and it is also not the point of contention. 

> So any mismatch between the DOMs and ECMAScript implementations, from which 
> they are derived, exists only in the mind of the person arguing that an 
> interface should allow the very thing that defeats its purpose.

All I can do is sigh at this... You misunderstand I.M. as well as attacked a strawman here

[toc] | [prev] | [next] | [standalone]

#22907

Michael Haufe (TNO) wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Christoph Michael Becker wrote:
>> > I believe at least one of the arguments Michael has made, is that the
>> > DOM defines interfaces, but not actual objects ("classes"), which can
>> > be
>> > extended.  While a particular DOM implementation might expose an
>> > Element
>> > object, for instance, this is not mandatory.  For that reason alone it
>> > is not possible to reliably extend DOM objects (let alone the problem
>> > that they are host objects, and ECMAScript leaves broad room for the
>> > actual behavior of these), what may be regarded as (impedance)
>> > mismatch.
>> 
>> That would be a specious argument, then.  The very purpose, and the
>> benefit, of an interface in OOP is that an object implementing it
>> provides a well- defined minimum set of properties and methods, [...]
> 
> ..and yet it is not only a minimum is it? The implementations must be
> treated as maximums as well, which contrary to the idioms of the language.

How did you get those ideas?
 
>> [...] whereas how the methods are implemented is left to the object,
>> allowing for, but not requiring, polymorphism.
> 
> There are at least five types of polymorphism, I assume you're referring
> to Ad-Hoc

I am aware only of three that are relevant here:

<https://en.wikipedia.org/wiki/Polymorphism_(computer_science)>

Apparently I was referring to “Ad-hoc polymorphism” and “subtyping”.
  
>> So any mismatch between the DOMs and ECMAScript implementations, from
>> which they are derived, exists only in the mind of the person arguing
>> that an interface should allow the very thing that defeats its purpose.
> 
> All I can do is sigh at this... You misunderstand I.M. as well as attacked
> a strawman here

What is this “I.M.” you are talking about?

-- 
PointedEars

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

[toc] | [prev] | [next] | [standalone]

#22928

Thomas 'PointedEars' Lahn wrote:

> What is this “I.M.” you are talking about?

"Immediate Mode" as mentioned in a former post[1].

[1] <news:b11baec5-d510-477c-8ebc-6e155f05139f@googlegroups.com>.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#22938

On Saturday, February 1, 2014 3:52:47 PM UTC-6, Christoph Michael Becker wrote:
> Thomas 'PointedEars' Lahn wrote:
> 
> > What is this "I.M." you are talking about?
> 
> "Immediate Mode" as mentioned in a former post[1].

Impedance Mismatch actually.

[toc] | [prev] | [next] | [standalone]

#22992

Michael Haufe (TNO) wrote:

> On Saturday, February 1, 2014 3:52:47 PM UTC-6, Christoph Michael Becker wrote:
>> Thomas 'PointedEars' Lahn wrote:
>>
>>> What is this "I.M." you are talking about?
>>
>> "Immediate Mode" as mentioned in a former post[1].
> 
> Impedance Mismatch actually.

Thanks for the correction. :)

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.lang.javascript

csiph-web