W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2015

RE: Defining a constructor for Element and friends

From: Domenic Denicola <d@domenic.me>
Date: Tue, 13 Jan 2015 17:25:56 +0000
To: Boris Zbarsky <bzbarsky@mit.edu>, Anne van Kesteren <annevk@annevk.nl>, WebApps WG <public-webapps@w3.org>, "www-dom@w3.org" <www-dom@w3.org>
Message-ID: <CY1PR0501MB136970E8CD419C8B73FBC151DF400@CY1PR0501MB1369.namprd05.prod.outlook.com>
From: Boris Zbarsky [mailto:bzbarsky@mit.edu] 

> But it also means that user-space code that has to create an HTML element generically now has to go through document.createElement instead of being able to do |new HTMLElement("a")|, right?

That seems totally fine to me though. The idea of a string-based factory for when you don't know what constructor you want to use has precedent all over software design.

> Those aren't the same thing at all, right?  The prototype chain has absolutely nothing to do with internal slots, unless we're assuming some sort of vanilla untouched tate of the world.

Agreed. However, in a "normal" situation---where all constructors in the chain call super() appropriately, and nobody __proto__-munges, and so on---they should be the same. That's why I'm saying that implicitly it was probably also part of what I was thinking when writing that.

> Really, this idea of "primary interface" and your idea of "own-instance" seem fairly similar, right?  Except that "primary interface" can only refer to Web IDL interfaces, not user-defined subclasses... or something.

Yeah, that sounds about right. Honestly, own-interface was just my attempt at capturing a JavaScript concept that I work with pretty often ("this over here is a Foo; this over here is a Bar").

Received on Tuesday, 13 January 2015 17:26:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:43 UTC