Minimalist Classes

Quildreen Motta quildreen at gmail.com
Tue Nov 1 05:49:44 PDT 2011


While the class literal proposed by Jeremy is indeed nice, I think it
misses the point of *why* class literals are desirable. What you've
proposed can already be achieved, with the same "sugar" -- and without
introducing a new construct, so people using ES3 can also get it through a
library, etc -- by using object exemplars: Selfish, Prototoypes As Classes,
etc.

The e-mail Erik pointed has got most of it, though what I really think
class literals can bring in that makes them worth is a better and
declarative syntax for private/const members and traits. Static shape can
be achieved through `Object.freeze', right? I don't think that should be
what classes strive to provide. Yeah, static analysis is nice and all, but
I believe that goes against the nature of the language's own semantics, and
if classes are supposed to be just sugar over prototypical inheritance
(with the added benefits I mentioned previously), it makes more sense that
they don't make such shape guarantees, imho -- vendors could still optimise
for static shape, and fallback to non-optimised code if the instance's
shape change, which I guess is what is done today with prototypes(?) and
which I think should also be done for `with', but I digress.

Still straying a bit from the main subject here, I thought type guards were
supposed to be defined at the function level, no? Or is it that the shape
of classes would be used to determine the types used?



2011/11/1 David Herman <dherman at mozilla.com>

> There may be something wrong with the above -- but dynamic super() should
> be a solveable problem for JS.next, even if not entirely desugar-able into
> ES3 terms.
>
>
> The problem isn't so much whether it's possible to come up with a
> semantics by changing the runtime; I'm sure we could do that. The problem
> is finding a way to get the semantics you want without taxing the
> performance all other function calls in the language. (Also known as a
> "pay-as-you-go" feature: if you don't use the feature, it shouldn't cost
> you anything.) We don't know how to do that for super().
>
> So I guess in theory I agree it'd be nice if super() and class could be
> designed completely orthogonally, but in practice they affect each other.
> But at the same time, I think a class syntax where the body is restricted
> to be declarative is actually a nice sweet spot anyway. You can still
> dynamically create classes just like always, but the declarative form gives
> you a sweet and simple syntax for the most common case.
>
> Dave
>

Yes, |super| is static to avoid the cost of passing an additional parameter
to every function call, whether that uses |super| or not.
Object.defineMethod is provided to make functions with bound |super| to
other objects. I also think that dynamic |super| makes more sense with
JavaScript, but vendors are concerned about performance -- plus,
Object.defineMethod should cover the other cases, albeit not as nicely as
dynamic |super| would.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111101/087f5dd3/attachment.html>


More information about the es-discuss mailing list