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

[Bug 23623] Support [Clamp] for sequences

From: <bugzilla@jessica.w3.org>
Date: Fri, 25 Oct 2013 01:40:37 +0000
To: public-script-coord@w3.org
Message-ID: <bug-23623-3890-uGITR1kzbx@http.www.w3.org/Bugs/Public/>

Nils Barth <nbarth+w3bugzilla@google.com> changed:

           What    |Removed                     |Added
                 CC|                            |nbarth+w3bugzilla@google.co
                   |                            |m

--- Comment #6 from Nils Barth <nbarth+w3bugzilla@google.com> ---
Anne, it's tempting to attach extended attributes to types, but the grammar
(and semantics) are significantly easier if we attach to operation arguments
(and members) instead. Syntactically:
[ExtAttr] sequence<long> foo
...instead of:
sequence<[ExtAttr] long> foo

This is b/c extended attributes appear at 3 levels:
* definitions (interfaces etc.),
* members (attributes, operations, etc.),
* arguments (to operations).

Extended attributes basically don't attach to types; if they did, we'd need to
handle nesting, so these would have different meanings:
[ExtAttr] sequence<long> foo
sequence<[ExtAttr] long> foo
...and there would be ambiguity of whether an ExtAttr applies to a type or an
argument (or an attribute etc.); this:
[ExtAttr] sequence<long> foo
parses 2 ways:
([ExtAttr] sequence<long>) foo
[ExtAttr] (sequence<long> foo)
...which is pretty ugly.


Note that in the Candidate Recommendation, extended attributes are applicable
to typedefs:
typedef [Clamp] octet Value;
in principle expands to:
sequence<[Clamp] octet> 
...but this makes quite a mess (as above), and is not present in the Editor's

Hope this helps!

You are receiving this mail because:
You are on the CC list for the bug.
Received on Friday, 25 October 2013 01:40:39 UTC

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