What is "super-intuitive" about running 'class C' up against an arbitrary
expression, which is then evaluated and *copied* (details fuzzy here) as the
class prototype?
Arguments about feelings and intuition are not that helpful. Saying why you
need to construct a class that way, where no such o
I noticed the absence of setter's, getter's. Would this be valid syntax?
set health(value) {
if (value < 0) {
throw new Error("Health must be non-negative.");
}
@health = value;
}
On Nov 3, 2011, at 12:17 AM, Brendan Eich wrote:
> What is "super-intuitive" about running
On 3 November 2011 01:12, David Herman wrote:
> ES6 modules are not extensible, for a number of reasons including
> compile-time variable checking. But of course API evolution is critical, and
> it works; it just works differently. Monkey-patching says "let the polyfill
> add the module exports
I'm not just talking about implementors, either. Some users
will want to know d.m isn't going to change. They may not
want to know that it's b.m, mind you -- they simply won't
want that c.m assignment to be legal, or else if they do
support such a thing, they don't want it to affect d's "vtable
Sorry, I'll try to be more clear.
What's "super-intuitive" isn't *that* you use the form "class name expr", it's
how you interact with that form once you know what it does. The reason is
self-evident—people know how to work with object literals and functions. This
is not true of the Leather f
>
>
> There are many more, I'm sure, but the point is this: a syntax that makes
> use of the elements already in the language (instead of providing
> alternates) is going to be more familiar and therefore objectively more
> intuitive. Yes, the class keyword brings some new wrinkles, but that will
>
I think Claus summarizes nicely what I've been thinking about this thread,
and the opposition-for-the-sake-of-opposition that has been spreading
through the JavaScript community. Though most of that seems to be based on
"JavaScript should be kept simple." I'd argue there doesn't need to be
conflict
On Nov 3, 2011, at 1:23 AM, Kam Kasravi wrote:
> I noticed the absence of setter's, getter's. Would this be valid syntax?
Yes, that's already in object literal syntax.
My gist is a fork of Jeremy's, he didn't add 'em so I didn't either. At this
point they are context, assumed. They're in ES5!
FWIW: I’ve picked what I like from the various proposals.
https://gist.github.com/1336846
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
h
I like this one mainly for the line
class declarations and object literals should have the same features
However if they have the same features then why bother with class at all.
Why not just have
let Monster = Being <| { ... }
This way we don't introduce the class keyword which is confusing a
I agree 100%. I still hope that object exemplars will become part of the
language. However they *are* introducing a completely new way of implementing
types (or rather, of naming exemplars). That is bound to be a deal-breaker for
many. Thus, if I can’t have object exemplars, I’ll settle for the
+1,000,000
Minor quibbles
get rid of
[incAge]: ...
just make it
@incAge
we don't need both [propname] and @propname in property declarations and
@propname has a narrower meaning (which is good). Also, I don't want to
unnecessarily couple object/class declaration syntax with [ ] semantic
I’ve updated the gist with (most of) your suggestions and rationales for the
decisions.
> Minor quibbles
>
> get rid of
> [incAge]: ...
> just make it
> @incAge
>
> we don't need both [propname] and @propname in property declarations and
> @propname has a narrower meaning (which is good).
Yes, good point about loaders. I would like a standard HTML way of specifying a
loader to use, so you could simply say:
and from then on your clients don't have to change a thing.
Dave
On Nov 3, 2011, at 2:00 AM, Andreas Rossberg wrote:
> On 3 November 2011 01:12, David Herman wrote:
>>
>
>
> I know this will be controversial, but I would prefer only having the
> expression form. The reason is that
>
> let Monster = Being <| mylib.mixin(Evil, Scary) <| class {...}
>
> is an important usecase and it is harder to make the syntax work with a
> pure class declaration.
>
>
I'm not su
Can loaders be composed (e.g. to use several polyfills at the same time)? One
might be able to chain them in some fashion.
> Yes, good point about loaders. I would like a standard HTML way of specifying
> a loader to use, so you could simply say:
>
>
>
> and from then on your clients don't
On Nov 3, 2011, at 6:53 AM, Matthew Tretter wrote:
> Sorry, I'll try to be more clear.
>
> What's "super-intuitive" isn't *that* you use the form "class name expr",
> it's how you interact with that form once you know what it does. The reason
> is self-evident—people know how to work with obje
Possibly, although it could be tough; I'll keep this in mind as we nail down
the API details.
Dave
On Nov 3, 2011, at 11:18 AM, Axel Rauschmayer wrote:
> Can loaders be composed (e.g. to use several polyfills at the same time)? One
> might be able to chain them in some fashion.
>
>> Yes, good
Alternative for polyfills: A loader that maps module names to alternate
implementations. This reminds me of dependency injection.
Potential problem: The path of a (non-built-in) library might not always be a
good ID (one module loads a minified version, another doesn’t). Maybe we need
some kind
Hi,
Last month, Mark Miller gave a series of talks at the University of
Brussels on SES and capability-based security. The videos of the talks have
now been made fully available on Youtube. I think this may be of interest
to some on this list. As many of you know, Mark uses ECMAScript 5 as a
found
> "freedom" includes my ability to fence my yard.
yep, but that fence can't be removed ever after.
and if there are irremovable fences, it's important to make sure, they
do not rise by themselves.
e.g. requiring "public" (thanks for not doing that:)
freezing module scope.
adding better syntax for
On Thu, Nov 3, 2011 at 12:52 PM, Tom Van Cutsem wrote:
>. Also, I heartily recommend the talks to
> those not entirely convinced of the necessity of private/const/frozen
> features. Mark makes a pretty good case for encapsulation as a necessary
> building block for ocap-based security
If I unders
We had this in ES4, together with the provision that you could have multiple
arguments between the [], so you could define data structures that can be
addressed as:
matrix2d[x, y]
As in here, this would default to the ES5 semantics on objects that don't have
the new [] proxy handler.
Overa
On 10/19/2011 08:16 AM, Allen Wirfs-Brock wrote:
Does anybody know or see a good reason why FunctionExpressionshouldn't be move
as a RHS of PrimaryExpression? MemberExpressionis the only occurrence of either
PrimaryExpressionor FunctionExpressionon the RHS of a grammar rule.
As you note, the
On 11/02/2011 04:10 AM, David Bruant wrote:
Another topic:
-
class Monster {
private name, health;
sameName(other) {
return @name === other@name;
}
}
-
I am under this impression that you are accessing the private property
("other@name") of an instance which isn't you (other !== this)
On Thu, Nov 3, 2011 at 2:10 PM, John J Barton
wrote:
> On Thu, Nov 3, 2011 at 12:52 PM, Tom Van Cutsem
> wrote:
> >. Also, I heartily recommend the talks to
> > those not entirely convinced of the necessity of private/const/frozen
> > features. Mark makes a pretty good case for encapsulation as a
On Nov 3, 2011, at 1:56 PM, Harutyun Amirjanyan wrote:
>> "freedom" includes my ability to fence my yard.
> yep, but that fence can't be removed ever after.
> and if there are irremovable fences, it's important to make sure, they
> do not rise by themselves.
That's completely false. If my "fence"
On 11:59 AM, Mark S. Miller wrote:
Note that I don't see any realistic way to fix problem #3 in the
ES.next language. My point is only that defensive programming is
tricky even after you've gotten all the formal properties you need. As
ES.next introduces various new abstraction mechanisms, whet
[I’m sending this email for Claus Reinke, because when he sends it, es-discuss
blocks it]
There is a new mailing list for Javascript tool developers,
intended to complement the es-discuss list's language
design and specification topics:
http://groups.google.com/group/js-tools
Please see the a
Is there a summary of the current status of standardized dependency
based script loading somewhere? Since the sync and async camps of
commonJS were unable to agree, we left with two sets of incompatible
JS libs and a few gymnastic boilerplate adapters to bridge them.
Perhaps a standard could do no
> Is there a summary of the current status of standardized dependency
> based script loading somewhere? Since the sync and async camps of
> commonJS were unable to agree, we left with two sets of incompatible
> JS libs and a few gymnastic boilerplate adapters to bridge them.
> Perhaps a standard co
On Thu, Nov 3, 2011 at 7:43 PM, Axel Rauschmayer wrote:
>> Is there a summary of the current status of standardized dependency
>> based script loading somewhere? Since the sync and async camps of
>> commonJS were unable to agree, we left with two sets of incompatible
>> JS libs and a few gymnastic
On Nov 3, 2011, at 7:53 PM, John J Barton wrote:
>> ES.next:
>> http://wiki.ecmascript.org/doku.php?id=harmony:modules
>
> I guess you meant:
> http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders
> but my question was more about whether this had any forward momentum,
> implementations e
33 matches
Mail list logo
