W3C home > Mailing lists > Public > public-script-coord@w3.org > October to December 2014

Re: Determining what prototype should be used for an object

From: Anne van Kesteren <annevk@annevk.nl>
Date: Sun, 16 Nov 2014 10:13:38 +0100
Message-ID: <CADnb78iUQEpGHj20fFCUqVc_RWpLzuyBO1dbuqc+C5Cxf0bizw@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: Allen Wirfs-Brock <allen@wirfs-brock.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>, Ian Hickson <ian@hixie.ch>
On Sat, Nov 15, 2014 at 1:06 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 11/14/14, 2:20 PM, Boris Zbarsky wrote:
>> Though maybe we don't want to tie this to [NewObject] and instead just
>> say that an object that's created gets created in the current Realm,
>> with an opt-out for specs to use the Realm of "this" as needed, and just
>> manually adjust things like getContext.
> The main issue with this approach is that I suspect it makes creating an
> object much more complicated.  Specifically, it requires that creating an
> object specify that all "built-in" property values on the object that are
> owned by it are created at the same time, using the same Realm as the object
> creation itself (since that's the conceptual model).
> This is problematic, since multiple specs can define partial interfaces that
> add new properties to objects...
> Maybe we can figure out a way to spec this that's clear, but I haven't
> though of one yet using this approach.

I'm not exactly following how partial interfaces are problematic here.
Once you gather them all you have a complete picture of the object,

If this is about internal slots, I would be interested in exposing those in IDL.

  class Event {
    String [[type]];
    get type()
    set type()

Combined with convenience syntax that could make the full structure of
a class much more clear.

Received on Sunday, 16 November 2014 09:14:06 UTC

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