Path: csiph.com!usenet.pasdenom.info!gegeweb.org!usenet-fr.net!feeder1-2.proxad.net!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail Content-Type: text/plain; charset="UTF-8" Message-ID: <2689391.ZCeiWr7303@PointedEars.de> From: Thomas 'PointedEars' Lahn Reply-To: Thomas 'PointedEars' Lahn Organization: PointedEars Software (PES) Date: Tue, 28 Jan 2014 21:18:47 +0100 User-Agent: KNode/4.11.3 Content-Transfer-Encoding: 8Bit X-Face: %i>XG-yXR'\"2P/C_aO%~;2o~?g0pPKmbOw^=NT`tprDEf++D.m7"}HW6.#=U:?2GGctkL,f89@H46O$ASoW&?s}.k+&. <1fe2e508-cfc8-4933-997b-9bb462a2a593@googlegroups.com> <4250784.k5hfLq1mn1@PointedEars.de> <2748480.FELbIWn90F@PointedEars.de> <2158405.4KzAjcCDC7@PointedEars.de> <4006284.34SQex3vo1@PointedEars.de> <52e7fbdd$0$9504$9b4e6d93@newsspool1.arcor-online.net> MIME-Version: 1.0 Lines: 83 NNTP-Posting-Date: 28 Jan 2014 21:18:49 CET NNTP-Posting-Host: d37669ea.newsspool1.arcor-online.net X-Trace: DXC=9hDaI6m@8OI[6=1B@oB@@@ic==]BZ:afN4Fo<]lROoRAnkgeX?EC@@@KPeR?^YhTLGDZm8W4\YJNLYUVHKH;GI^GA:4gUTI10KA1FEU\Y5IYGE X-Complaints-To: usenet-abuse@arcor.de Xref: csiph.com comp.lang.javascript: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: >>> >>> >>> >>> >>> >>> >> >> 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.