- From: <bugzilla@jessica.w3.org>
- Date: Tue, 30 Sep 2014 02:16:50 +0000
- To: public-script-coord@w3.org
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