This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 21270 - Introduce syntax for getters that keep returning the same object
Summary: Introduce syntax for getters that keep returning the same object
Status: RESOLVED FIXED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: WebIDL (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Cameron McCormack
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 21271
  Show dependency treegraph
 
Reported: 2013-03-13 17:05 UTC by Anne
Modified: 2013-08-02 06:08 UTC (History)
5 users (show)

See Also:


Attachments

Description Anne 2013-03-13 17:05:12 UTC
It would be nice if we could annotate e.g. Node.childNodes and Element.attributes in IDL with something that indicates the same object will be returned each time.

Gecko has [Constant] for this. We could maybe have something like NodeList* to indicate it returns a pointer rather than a new object (in C terms...).

Alternative we could maybe say that this is the default and use "new NodeList" for the other case, but then there are some getters that will sometimes return the same object and sometimes a new one. Or maybe say that unless the prose uses the word new, it must be taken as the same object will be returned each time...
Comment 1 Boris Zbarsky 2013-03-13 17:10:40 UTC
I bet the prose for .firstChild never mentions "new".  ;)
Comment 2 Travis Leithead [MSFT] 2013-03-13 17:25:28 UTC
I like the idea of a concise syntax that describes this (without needing to use a verbose extended attribute); however, I don't like the asterisk (*) since it's an overloaded concept with C.
Comment 3 Cameron McCormack 2013-03-25 05:44:00 UTC
I think this is would be a reasonable addition, although I think it should be opt in rather than the default.  What about:

  interface Node {
    const attribute NodeList childNodes;
  };

That reads nicely to me, with the small downside of complicating the LL(1) grammar.
Comment 4 Cameron McCormack 2013-08-02 06:08:40 UTC
Resolved here: http://lists.w3.org/Archives/Public/public-script-coord/2013JulSep/0133.html