ES4 draft LAST CALL: Map
I have a question related to collections in general.
I have the impression that ES4 will someday accept some kind of high-level concurrency, possibly Erlang-style. If so, we will probably need the ability to perform some kind of (destructive) pattern-matching/switch-type on the contents of a collection. Now, maybe this kind of pattern-matching will only needed for some concurrency-specific data structure, say a dynamically-typed Mailbox (à la Erlang) or a statically-typed Channel (à la Concurrent ML) or perhaps something higher-level (à la JoCaml).
With the current definition of Map and collections, this form of pattern-matching may probably be hand-coded using an iterator and intrinsic::remove, although the process is relatively unfriendly and the thread-safety will remain uncertain until there's a concurrency model for ES4.
Now, on to my question: should we add a method for finding some data in a collection from destructive pattern-matching or should this be left for later ?
Cheers, David
Quoting Lars Hansen <lhansen at adobe.com>:
A later version of ES may or may not embrace some sort of concurrency solution. (It seems likely, but who knows.) I don't think it's possible to say anything about what form that might take, except I'm fairly sure that shared-memory threads won't be it.
My opinion is that if there are features that are primarily useful for concurrency (and it sounds like what you have in mind is that) then we should not try to guess about them until we start talking about concurrency in earnest.
On Fri, 2008-03-21 at 14:46 +0000, Lars Hansen wrote:
My opinion is that if there are features that are primarily useful for concurrency (and it sounds like what you have in mind is that) then we should not try to guess about them until we start talking about concurrency in earnest.
--lars
Ok. Other than in a concurrency, this destructive pattern-matching may occasionally be useful, but I guess re-implementing it by hand is simple enough that it probably doesn't need to be built-in collections.
-----Original Message----- From: David Teller [mailto:David.Teller at univ-orleans.fr] Sent: 21. mars 2008 08:08 To: Lars Hansen Cc: es4-discuss at mozilla.org Subject: RE: ES4 draft LAST CALL: Map
On Fri, 2008-03-21 at 14:46 +0000, Lars Hansen wrote:
My opinion is that if there are features that are primarily useful for concurrency (and it sounds like what you have in mind is that) then we should not try to guess about them until we start talking about concurrency in earnest.
--lars
Ok. Other than in a concurrency, this destructive pattern-matching may occasionally be useful, but I guess re-implementing it by hand is simple enough that it probably doesn't need to be built-in collections.
Feel free to air concrete thoughts, if for no other reason than for the record. Just because we're trying to nail down ES4 doesn't mean we have to stop talking about the design space.
The current definition in 1.2.2 of what Map(o) does is a harmful dead end. The current behavior is:
- If o is already a Map then leave it alone.
- Otherwise enumerate the visible properties of o and construct a Map out of those.
This is harmful because it's guaranteed to cause current and future incompatibilities. There are many other map-like things for which this is the wrong default and we'll be unable to fix them for compatibility reasons. Here are just a few:
- If you construct a Map out of a Vector, you want the mapping of indices to the elements, with nothing else. The default behavior brings in extraneous miscellaneous housekeeping properties (length, maybe fixed, perhaps more in the future).
- Folks will write libraries that define MultiMap and Set classes. We'll want to later allow natural conversion of these to a Map, but the default will get in the way.
For these reasons the current definition of Map(o) is broken and should not be adopted. The fix is to take out the auto-enumerating behavior. If it's needed, it should be done by a static function.
Waldemar
Last call for comments. Minor changes since previous drafts (and some comments at the beginning to address changes that are known to come).