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

[Bug 23682] Fix the current [ArrayClass], [] and sequence<T> mess

From: <bugzilla@jessica.w3.org>
Date: Tue, 30 Sep 2014 02:16:50 +0000
To: public-script-coord@w3.org
Message-ID: <bug-23682-3890-AN516PrJjy@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23682

--- Comment #23 from Jonas Sicking <jonas@sicking.cc> ---
So, to be clear, the Array+observing pattern only happens in the solutions to
use-case D. And it only happens in solutions 1 and 2 (from comment 12) to that
use case.


Regarding your question about "why do we just not just use Array-like DOM
classes". Is this specifically for D? Or for all of the use cases?

If just for D, I somewhat understand the argument. Though I'll note that at
best this still only gets us to something very similar to solution 2 from
comment 12. The main difference is a different implementation strategy, and the
ability to do type checks. Neither of which are huge benefits.

And the more I think about the three options in comment 12, the more I think
option 3 is the simplest. It makes properties that have array-like values
behave like other properties. And as an added bonus, in this solution existing
JS-Arrays work really well. Using Array-like DOM interfaces wouldn't improve
that solution at all.


I don't know what other APIs that we're planning on using Map-like or Set-like
values. So I can't really comment on if it makes sense that they behave
differently from Array-like values.

In all APIs where I've wanted to use a Map-like or a Set-like it has been to
expose an immutable set/map. So reacting to changes or enforcing types hasn't
been needed.

The only API I've seen that has wanted to use a mutable Map/Set was the
FontLoader API and using a mutable Map-like/Set-like didn't seem like a good
fit there either.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Received on Tuesday, 30 September 2014 02:17:03 UTC

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