Speaking of Lisp...

Peter Hall peterjoel at gmail.com
Fri Jan 5 18:55:45 PST 2007

Yes, they are native to the Flash Player, not AS3 in general - though
there is of course currently no practical separation...


But Dictionary does not solve the pollution problem by itself, as it
still inherits from Object. You'd need to extend Proxy and
specifically handle identifiers that conflicted with members of


On 1/6/07, Brendan Eich <brendan at mozilla.org> wrote:
> On Jan 5, 2007, at 6:33 PM, Peter Hall wrote:
> > While identifiers can be QNames, does that automatically mean that
> > it's useful to use QNames for hash keys? Probably not.
> It's not clear to me whether E4X *requires* QNames as hash keys.  One
> way of reading it (when I implemented it) says "yes".
> > But, even so, I don't see a big barrier if qualified keys were
> > required. For QNames with non-empty namespace URI, there would be no
> > pollution problem and for unqualified keys you could add a prefix to
> > prevent collision with Object.prototype.
> One often wants a hash from string to value, no QNames or namespaces
> involved.
> > Something like AS3's Proxy object would mean you could encanpsulate
> > that implementation quite cleanly too. I'd prefer to see AS3's Proxy
> > and Dictionary classes added to ES4 before more strange syntax - ES4
> > is already filling up with a lot of new notations and concepts, that
> > would be unfamiliar and difficult to many existing JS/AS developers.
> Let's not get stuck on syntax -- I made up #{...} because I know of
> use-cases for an object initialiser where Object.prototype does not
> pollute the hash.  Whether you have to use B&D-language class-ical
> OOP, or lighter-weight JS object "literal" syntax, we can wave off
> (ok, I'm baiting/teasing a little in this sentence ;-).
> Sounds like one vote for a Dictionary class.  Could you cite some
> URLs documenting Proxy and Dictionary from the Flex SDK (I'm assuming
> these are not "AS3" but "host" types).
> /be

More information about the Es4-discuss mailing list