W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2013

Re: How to specify an object that can be mutable or immutable

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Thu, 26 Sep 2013 11:13:51 -0400
Message-ID: <52444F2F.5090200@mit.edu>
To: public-script-coord@w3.org
On 9/26/13 8:15 AM, Domenic Denicola wrote:
> Can somebody spell out how this proposed inheritance hierarchy works in actual ECMAScript, not WebIDL?

In ES5 (because I'm not up to date on ES6 class syntax), and ignoring 
the .constructor hookups and whatnot:

function DOMRectReadonly() {
   // Some stuff here
}
DOMRectReadonly.prototype = Object.create(Object.prototype,
{
   left: {
     get: function left() {
            // stuff here
          }
   }
   // more members
};


function DOMRect() {
   // Some stuff here
}
DOMRect.__proto__ = DOMRectReadonly;
DOMRectReadonly.prototype = Object.create(DOMRectReadonly.prototype,
{
   left: {
     get: function left() {
            // stuff here, which is a copy-paste of the getter on
            // DOMRectReadonly.prototype, or an invocation of the
            // canonical version of that getter.
          },
     set: function set_left(arg) {
            // stuff here
          }
   }
   // more members
}

I _think_ in terms of ES6 classes this would be:

class DOMRectReadonly {
   get left() {
     // stuff here
   }
}

class DOMRect extends DOMRectReadonly {
   get left() {
     // stuff here
   }
   set left(arg) {
     // stuff here
   }
}

but I can't find a good non-specese description of ES6 classes, so I'm 
not sure.

> For example, if readonly is taken to mean non-writable non-configurable data properties

But it's not.  To read webidl, you should really... read webidl.  In 
this case http://dev.w3.org/2006/webapi/WebIDL/#es-attributes

> Or if it's meant to be getters only

Right.

> then you should be able to bypass that protection by using the subclass setter applied to a superclass instance.

Except all this stuff checks branding.

> I am very concerned that the design thinking here is not taking place at the level of the language in which these constructs manifest.

In my head, it actually is, because I view the IDL as a shorthand for 
what will actually happen at runtime.  It's certainly a lot more concise 
than the ES5 above, or even the ES6.  And most of the people involved 
don't know the ES6 syntax anyway, again because there seems to be no 
good official guide for it.

-Boris
Received on Thursday, 26 September 2013 15:14:24 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:50 UTC