brendan at mozilla.org
Mon May 19 19:27:56 PDT 2008
On May 19, 2008, at 5:41 PM, Mark S. Miller wrote:
> On Mon, May 19, 2008 at 4:42 PM, Brendan Eich <brendan at mozilla.org>
>> On May 19, 2008, at 4:22 PM, Mark S. Miller wrote:
>>> But ES4 is also sideways in this sense. There's a bunch of stuff in
>>> Mozilla's JS1.8 that didn't make it into ES4.
>> Namely? As noted, some pieces are prototypes that will be adjusted
>> to match
>> the ES4 type-based counterpart (the iteration protocol hook,
>> e.g.). What
>> bunch of stuff is in 1.8 that did not make it into the latest ES4
> Ok, I looked, and it's a lot less than I expected. "watch" is an
> example. (Unless I didn't notice its inclusion).
Object.prototype.watch and unwatch have been in SpiderMonkey for ~12
years (memory fades -- in rev 1.1 on cvs.mozilla.org, I recall
implementing in Netscape's private CVS years before mozilla.org was
>>> Also, there's a tremendous amount of stuff in ES4 that was never
>>> in a
>> Except under the hood, off limits to programmers, reserved for the
>> and the DOM.
> Huh? Classes, Type declarations, Namespaces!,
Classes under the hood (interfaces too) in built-ins and the DOM and
browser object models. You cannot bootstrap JS in JS without
something like classes.
Type declarations mean several things, but let's pick just structural
types: under the hood in SpiderMonkey at least.
Namespaces: fair enough, although the built-ins still get special
treatment. What else are the [[Get]], etc. "internal property names"
in ES1-3, but non-default namespace prefixes disguised as semantic
brackets. These names are mangled in a way that cannot be spelled in
the language, yet they are property names.
> perhaps Packages and/or
> Units, if these are still on the table.
They were cut -- please try to keep up, we ES4-ers are spending time
keeping up with 3.1 :-/.
> Namespaces is a huge addition to the complexity of the language, and
> the one I'm least happy about.
Actually, I agree with you that namespaces add more complexity than
classes alone (if that's what you mean). We've been working on them
for a long time (Waldemar can tell you about the first go-round).
They're too useful to lose in favor of privileged built-in names and
__UGLY__ conventions for the lusers.
>> and repeat that we wouldn't fold any 3.1 into a distinct *JS*
>> version number.
> Ok then, I'm happy to stop arguing about this. I just thought that
> this odd idea might be seen as helpful. If not, forget it. We have
> enough substantive issues to argue about ;).
Will do, although a transcendental version number will come in handy
some day, I'm sure ;-).
More information about the Es4-discuss