Benjamin Gruenbaum wrote:
Correct, I mean value types (or objects) that have value semantics and support
operator overloading.
We'll probably talk about that tomorrow in a break-out. At least I hope to!
More after this week's TC39 meeting.
/be
___
Christian Mayer wrote:
Am 18.11.2014 um 22:03 schrieb Brendan Eich:
Christian Mayer wrote:
What I actually sometimes really miss in JavaScript (having a big C++
background) are destructors.
(I haven't checked if they are in any new version proposal, though)
No, as JS has no stack
Christian Mayer wrote:
Am 18.11.2014 um 06:50 schrieb Biju:
Just want to add, usually in corporate world a .Net or Java developer
is who code JavaScript. The code above may be little complex for them.
What I actually sometimes really miss in JavaScript (having a big C++
background) are
Allen Wirfs-Brock wrote:
```js
Array[Symbol.isArray]] = true; //note, this is a constructor
property, not an Array.prototype property.
Minomer, then -- how about Symbol.isArrayClass?
we also change Array.prototype.concat to do the above Array.isArray
test instead of using
Dmitry Soshnikov wrote:
Is this something what is ready for discussion on a meeting (in
particular, tomorrow's meeting)?
You put something on the agenda, cool.
https://github.com/tc39/agendas/blob/master/2014/11.md
/be
___
es-discuss mailing list
Allen Wirfs-Brock wrote:
if (isProxy(obj)) return isArray(getProxyTarget(obj));
//Array.isArray(new Proxy(Object.create(Array.prototype), {}))
//I'm not sure that the above line is really a compat. issue. I'd
prefer to leave it out.
Please do -- it contradicts the righteous
Boris Zbarsky wrote:
On 11/15/14, 11:47 AM, Allen Wirfs-Brock wrote:
- hide quoted text -- show quoted text -
Actually the ES6 semantics does allow for this. The global object
would have t be implemented as a new kind of implementation specific
exotic object whose [[SetPrototypeOf]] internal
Tom Van Cutsem wrote:
No really, it was a way to expose a test of the [[Class]] internal
property. That test wasn't dependent upon the [[Prototype]] chain.
I think what Domenic was saying is that Array.isArray used such a test
*because* instanceof Array didn't work reliably
Tom Van Cutsem wrote:
2014-11-14 21:52 GMT+01:00 Jeremy Martin jmar...@gmail.com
mailto:jmar...@gmail.com:
Allen's previous comments:
Proxies are not transparent forwarders! In particular their
default handling of the `this` value on method invokes will
break any
Allen Wirfs-Brock wrote:
We might redefine Array.isArray to be based upon testing for
@@isConcatSpreadable but that potentially would give different results
for legacy uses that did __proto__ hacking such as I mentioned in my
previous mote.
How about we turn the @@ property into
Steve Fink wrote:
On a related note, I*would* like to have some way of getting the OS to
decommit memory. Seehttps://bugzilla.mozilla.org/show_bug.cgi?id=855669
(start reading at about comment 22) for our discussion and attempt at
this, which looks like it mysteriously trailed off this
Steve Fink wrote:
I'm not sure we're talking about the same thing. I'm talking about what
would be madvise(MADV_DONTNEED) on POSIX or VirtualAlloc(MEM_RESET) on
Windows. Er... actually, I think it would be MEM_RESET followed by
MEM_COMMIT to get the zero-filling while still releasing the
Andreas Rossberg wrote:
This brings me around to the position that let-like global instantiation should
reject let-shadowing of non-configurable property global properties such as
‘undefined’ and ‘window’.
All good points, I agree.
Agreed.
The VarNames list is actually support a
Jeff Walden wrote:
On 10/27/2014 06:53 PM, Allen Wirfs-Brock wrote:
The individual typed array constructors are supposed to inherit their
[[CreateAction]] from %TypedArray% and use the definition provided
Antony Courtney wrote:
expand(`Hello ${x} and ${y}!`, {x: 10, y: 12});
// == Hello 10 and 12!
From what I've seen of drafts of ES6 template strings, templates are
expanded automatically by evaluating the expressions enclosed in
${...} at the point where the template string literal
Brendan Eich wrote:
safe_html `${x}hello, ${u}/${x}`
But you're right, the
http://people.mozilla.org/~jorendorff/es6-draft.html copy I'm finding
template in online does not include this prefix form. Did it get cut
from ES6? I thought the only debate was whether to include unprefixed
Antony Courtney wrote:
I don't immediately see how this enables the more conventional model
of expansion with an explicit dictionary under control of the caller.
You don't need a template string if you want full quotation without
interpolation -- a string will do.
But why do you want a
Antony Courtney wrote:
function safe_html(template_string) {
// note: mapping dictionary d constructed explicitly, not based on
what's in scope where template literal appeared
var d = { x: 'strong', u: 'world'};
return template_expand(template_string, d);
}
Part of a realistic
Rick Waldron wrote:
Per Anthony's OP:
My particular application is that I want to use a template system to
construct SQL queries in a modular way. For this particular
application I want programmatic control over when and how the
expansion happens and won't have the escaped template
Allen Wirfs-Brock wrote:
On Oct 26, 2014, at 8:38 PM, Brendan Eich wrote:
Boris Zbarsky wrote:
If this is how Records work, it would be good to spell that out
explicitly.
Mutable records have reference, not value, semantics -- good point.
Some might object to calling any such spec
Allen Wirfs-Brock wrote:
Naming and other such editorial conventions can evolve, but in terms of
finishing ES6 they are lower priority than resolve remaining bugs and open
technical issues.
Easiest fix: s/\Record\/Struct/g or better. Just a thought, not
putting this on your plate, rather
Boris Zbarsky wrote:
If this is how Records work, it would be good to spell that out
explicitly.
Mutable records have reference, not value, semantics -- good point.
Some might object to calling any such spec-internal device a record.
This use of spec-internal reference-semantics mutable
Allen Wirfs-Brock wrote:
Arguably a design bug, rather than a spec. bug. But I'm assuming that who ever
originally wrote up these algorithms were being intentional about such things.
Design, vs. accidental. Spec, vs. implementation. Potato, Potahtoe :-P.
I think we should fix 'em as we find
Domenic Denicola wrote:
BTW I definitely agree that promise-returning `delay(ms)` as a better
`setTimeout` should be part of the standard library.
See https://twitter.com/garybernhardt/status/526435690524196864 where
I'm subtweeted but with some justice. setTimeout began life taking only
a
Allen Wirfs-Brock wrote:
On Oct 24, 2014, at 9:11 AM, Brendan Eich wrote:
André Bargull wrote:
IE11 moves elements up one index, throws a RangeError and completes
instantly (no hang or oom).
Per spec, huzzah -- but the spec needs fixing.
That conclusion isn't so obvious to me
André Bargull wrote:
IE11 moves elements up one index, throws a RangeError and completes
instantly (no hang or oom).
Per spec, huzzah -- but the spec needs fixing.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
Domenic Denicola wrote:
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Adam Klein
Is there any reason not to specify some precondition checking in these
algorithms and spec them to throw the RangeError without interacting with the
elements of the array if it's known
Allen Wirfs-Brock wrote:
I can only answer briefly right now: This is intentional. Array instances are
still limited to 2^32-2 elements. Compat issues to change. But, the generic
array methods aren't restricted to Array instances and support larger lengths
in those cases.
Hi Allen,
Allen Wirfs-Brock wrote:
ES5 didn't specify any precondition checks, so to do so now is, in theory, a
breaking change. In practice it might not matter, but nobody knows for sure.
Unlikely, given what Adam reported:
V8 properly throws a range error, but fails to move the element up one
Katelyn Gadd wrote:
Has the C# approach to namespace extension been considered at all?
Yes. ES4 has namespaces, after Common Lisp symbol packages.
Scoped object extensions were proposed four years ago for ES6, but
foundered on the same thing that killed ES4 namespaces: adding a second
Boris Zbarsky wrote:
Whether WindowProxy corresponds to Vat or not is an interesting
question, but I would guess in practice it does not.
Can you say more? We may end up with multiple distinct well-defined
concepts, but let's shave closer with Occam's razor, if possible.
/be
Mark S. Miller wrote:
Wait, I don't even understand what analogy y'all have in mind. A
Window is per Realm. A WindowProxy is per what? certainly not per Vat,
as there are many WindowProxies co-residing in the same Vat. I don't
see even any metaphorical similarity between a WindowProxy and a
Boris Zbarsky wrote:
On 10/16/14, 5:58 PM, Brendan Eich wrote:
Can you say more?
Vats as currently specified have independent event loops and allow
parallel JS execution, in the sense that they are totally disconnected
from each other and have separate run-to-completion guarantees
Allen Wirfs-Brock wrote:
realms and vats and ES jobs.
I like mixed metaphors as much as the next person, but srsly, can we talk?
Realm : Quest :: ??? : Job
Vat : Realm :: WindowProxy : Window
I'm not sure of these, help wanted fixing them and filling in the ???
slot -- but we have too many
Caitlin Potter wrote:
I’m not sure what the problem with `0xFE` is supposed to be, though?
Right, 0xFE is a fine hex literal. One must remember all the punning
uses of hex: 0xFEEDFACE, 0xFEEDBABE, 0xCAFE, etc.
/be
___
es-discuss mailing list
Alexander Kit wrote:
On 19 September 2014 01:52, Domenic Denicola
dome...@domenicdenicola.com mailto:dome...@domenicdenicola.com wrote:
ALL of these things can be accomplished with your own custom tag.
Yes, it can be accomplished with the custom tag function. But this is
not the
Domenic Denicola wrote:
That said, Set is shipping in every major browser so it's not going to
get fixed now.
Why do you say that?
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
John Lenz wrote:
or a simple utility method
Current keyword-anchored statement form does not require parens around
expression to evaluate and throw.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
Dmitry Soshnikov wrote:
The Collection protocol thus consists of at least .constructor,
@@iterator, .set. (Is there a better way to clone? Don't want a
new protocol where an old one will suffice!) This Collection
protocol would include Map and maplikes but leaves out Set, Array,
Brendan Eich wrote:
This meansMap.prototype.mapetc. -- or %ItereablePrototype%.map if not
Array.prototype.map etc. -- are the eager collection-generic companions.
Bear with me, trying to develop a half-thought. To say it with code:
```js
Object.defineProperty(%IteratorPrototype%, 'map
Caffeinating still, obvious bugfix below:
Brendan Eich wrote:
```js
Object.defineProperty(%CollectionPrototype%, 'map', {
value: function (fun) {
let result = new this.constructor();
for (let [key, val] of this) {
result.set(key, val);
```js
Domenic Denicola wrote:
Note the this.clone() call. This is novel, and required to avoid exhausting
the receiver iterator.
This is noteworthy and worth keeping in mind regardless of the rest of the
discussion. I think I would be fine having %IterablePrototype%.map exhaust the
iterator. I
Good to known (and I had heard this via Python community channels
already). Still feels wrong, given name polymorphism on `map`. Perhaps
we just plow ahead.
Still seems like someone (at some layer) will want iter.clone(). Vouch?
/be
Jason Orendorff wrote:
OnMon, Oct 6, 2014 at 1:34 PM,
Domenic Denicola wrote:
From: Brendan Eich [mailto:bren...@mozilla.org]
But entries returns an iterator, and if we define %IteratorPrototype% to
create a new instance of the right class given its|this| parameter, in this case
Map and not MapIterator, then no need for the new Map() wrapper
Dmitry Soshnikov wrote:
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Domenic
Denicola
- show quoted text -
Unless I'm missing something (quite possible!), I would prefer not to add
new methods to Map and Set when they could be added to %IteratorPrototype%.
Yeah,
Isiah Meadows wrote:
I mean that I wasn't thinking straight when I sent that. I'm incorrect
in every detail of that email.
No worries -- I'm interested in parser benchmarks, both in-JS and
C++-to-the-metal. Anyone else have any?
/be
___
es-discuss
Brian Di Palma wrote:
The recent thread on throwing errors on mutating immutable bindings
touched upon the fact that there is no static unresolvable reference
rejection in modules.
I was wondering if that was down to needing to allow access to
properties set on the global object?
If that's the
Isiah Meadows wrote:
True, and I don't know of a decently fast ES3/5 parser.
What is your use-case? For a parser in JS, is
http://marijnhaverbeke.nl/blog/acorn.html too slow? For C++ hand-coded
parser, what's your not-decently-fast benchmark basis code?
ES6 will be even more complicated,
Mark S. Miller wrote:
On Tue, Sep 30, 2014 at 4:58 PM, Domenic Denicola
dome...@domenicdenicola.com mailto:dome...@domenicdenicola.com wrote:
I see a few options:
1. Rename. The leading candidate would be `Array.prototype.has`. I
outlined in [1] why `contains` is better; note
Andrea Giammarchi wrote:
1. I wasn't advocating to break the web but to **not** change the
name because of a library bug, the initial thread spoiler was not needed
I wasn't responding to you, here on this thread (where you hadn't posted
till now) or on the other one, so why are you jumping
Claude Pache wrote:
The more I consider the issue, the more I think that the most elegant
solution is to complete data properties with an additional
overridable attribute, whose purpose is to refine the meaning of the
writable attribute in the manner sketched below (in opposition of
having an
Mark S. Miller wrote:
Does the [[Overridable]] you have in mind also fix the override
mistake? It sounds like it should.
Yes, definitely.
Regarding shadowable, is there any better documentation than the
doc-comment:
|/*|
| * For ES5 compatibility, we allow properties with
Kevin Smith wrote:
entries() returns an iterator, not an array.
let map2 = new Map([...map1].map(([k, v]) = [k, v * 2])
Sweet!
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Right.
Need a complete semantics: static and runtime. News at 11,
/be
Jason Orendorff wrote:
I think there is a way that the error could occur at runtime even in
all-strict-mode code: when a new const is added at toplevel in a
second script.
script
use strict;
function
Yup, and we've talked about this at TC39 meetings. We need a
simple-enough static analysis, and runtime errors for the residue that
escapes that analysis. I hope this is not controversial!
/be
Erik Arvidsson wrote:
The static error is problematic. I'm pretty sure that engines that do
lazy
Jason Orendorff wrote:
I'd love to be able to get rid of SHADOWABLE, actually! I just
recently found out we can do it with a little rearranging. Extra
state-space in property attributes is unavoidable complexity for us.
My own preference would be not to standardize it.:)
There's also the
Dmitry Soshnikov wrote:
Not ideal either. Usually langs provide nice declarative syntax for
such things. E.g. we have[1] the same in the HACK language, and use it
well everyday when need a map.
But this part is of course not for ES6, hope ES7-ish.
[1]
Axel Rauschmayer wrote:
We could definitely have Map and Set literals:
const map = {1 = one, two = true, false = three};
Would that be tricky to parse if keys can be arbitrary expressions
(incl. array literals)?
The issue would be arrow function expression keys:
const map = {x = x*x =
John-David Dalton wrote:
Just a heads up, I've pinged MooTools core to inquire about
fast-pathing a patch release for Array#contains.
Did you ask them to fix their code so it doesn't fail for any name, not
just for 'contains'? Thanks,
/be
___
David Herman wrote:
I'm usually less concerned about REPLs, since they can decide for themselves
what kind of context they want to execute in -- or even invent new non-standard
non-terminals, frankly -- although in this case it's not quite clear what a let
declaration*should* do in the REPL.
Mark S. Miller wrote:
That's why, IIRC (haven't checked lately), TCO is only specified for
calls from non-sloppy functions.
PTC (Proper Tail Calls), not TCO. It's confusing to equate the two, from
what I know (corrections welcome0.
To add to confusion, ES6 drafts say Tail Position Calls
Allen Wirfs-Brock wrote:
No particular reason an implementation can't optimize through that if they want
to.
The question is whether it should be normative. PTC is about observable
asymptotic space performance (I keep saying :-P).
/be
___
Allen Wirfs-Brock wrote:
On Sep 29, 2014, at 12:02 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
No particular reason an implementation can't optimize through that
if they want to.
The question is whether it should be normative. PTC is about
observable asymptotic space performance (I
Carl Smith wrote:
I still think the omission of some method for naming eval'ed code in
the ES6 spec is unacceptable. It's not a nice-to-have that can be
bundled with nicer stack objects, which are relatively unimportant
[easily fixed with a regex].
See
Carl Smith wrote:
If the source URL hack, or some cleaner wrapper for it, was
standardised, it'd make all the difference.
Why don't we just make the source URL hack a de-facto standard? That's
how evolution happens, in the best case. Cc'ing @fitzgen.
/be
Put it in a worker or node.js. The point Sam was making was based on Ecma-262,
no browser watchdog required.
/be
On Sep 29, 2014, at 6:47 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/29/14, 4:16 PM, Sam Tobin-Hochstadt wrote:
We'd consider it a spec violation (at least, I would), if this
Huzzah!
IIRC, http://nba.com had some JS in it many years ago. While still in
development, V8 developers noticed it. I hope it's all gone.
/be
Oliver Hunt wrote:
Hi all, as a heads up we’re going to be doing an experiment in our
tree to see if we can kill off the function.arguments property
Tab Atkins Jr. wrote:
I don't understand how you inferred from Andrea's post that this
wish-fulfillment __noSuchProperty__ magic property does not have to
handle superclass delegation..
I did not infer that from Andrea's post as his position -- rather the
reverse, because he said I also think
Dean Landolt wrote:
Out of curiosity, wouldn't Object.observe require implementors to add
precisely this kind of hook into the vm anyway?
No, but O.o has its own costs. See
http://lists.w3.org/Archives/Public/public-script-coord/2014JulSep/0204.html
/be
Brendan Eich wrote:
Dean Landolt wrote:
Out of curiosity, wouldn't Object.observe require implementors to add
precisely this kind of hook into the vm anyway?
No, but O.o has its own costs. See
http://lists.w3.org/Archives/Public/public-script-coord/2014JulSep/0204.html
To say a bit more
Konstantin Ikonnikov wrote:
Can I import module dynamically, but synchronously? Example for common js
```js
var moduleName = 'foo';
var foo = require(moduleName);
```
You can't do that in the browser, as followups point out. Do you use
browserify or similar to make this seem to work? If so,
Dean Landolt wrote:
http://lists.w3.org/Archives/Public/public-script-coord/2014JulSep/0204.html
Sure, O.o isn't free, and I get that using @noSuchProperty would
likely result in all kinds of deoptimization. But of all the costs
listed in that thread, I'm not seeing any mention of the
Brendan Eich wrote:
A general-purpose (as its name implies) nSP would hit lookup (get as
well as set) paths, not just mutation (set). But it seems Andreas's
just to clear up some myths words were missed, even considering only
mutation (not notification).
From private correspondence
Tab Atkins Jr. wrote:
Any nSP of the kind we seem to be discussing would need to fail fast, on
evaluation of the dot expression. That is a fast path.
I, personally, have only ever used Python and PHP's nSP functionality
to implement methods. Most of the fancy uses I see for it in, say,
Ruby
On Sep 25, 2014, at 7:56 PM, Boris Zbarsky bzbar...@mit.edu wrote:
SpiderMonkey used to support __noSuchMethod__, I believe.
I implemented __noSuchMethod__ long ago, for the TIBET folks (Smalltalk style
JS framework; they wanted a doesNotUnderstand analogue).
Please note well the difference
C. Scott Ananian wrote:
On Wed, Sep 24, 2014 at 2:36 AM, Viktor Mukhachevesdiscus...@yandex.ru wrote:
RegExp.prototype.exec returns array with extra properties (input, index),
may be it is better to return something other for `run`, frozen value object with
`0`, `1`, ... keys for example.
Hi Fabrice,
Thanks for the proposal, I ran it by TC39 yesterday and it advanced to
stage 0. This means work getting to stage 1, per:
https://docs.google.com/document/d/1QbEE0BsO4lvl7NFTn5WXWeiEIBfaVUF7Dk0hpPpPDzU/edit
The committee liked it not only for emulating int64 and uint64 more
Brendan Eich wrote:
Tab Atkins Jr. wrote:
This works great as a general principle, but honestly tons of
languages have already forged this path. It's pretty straightforward,
I think.
I made the case for building it in sooner, but TC39 wanted less
sooner based on library usage
Tab Atkins Jr. wrote:
Using subclassing to bung in some arbitrary trait is really terrible.
:/ It requires either adding it up high in your class hierarchy, or
having to write a custom NoSuchPropertyClass which extends your
superclass, so you can then extend it.
Ok, let's not hand-wave mixin
Hemanth H.M wrote:
It is one proposed syntax for async functions.
Cool, thanks.
Not sure who wrote the -cited line -- Jeremy didn't.
On Tue, Sep 23, 2014 at 7:30 PM, Jeremy Martin jmar...@gmail.com
mailto:jmar...@gmail.com wrote:
This has come up a few times. Check out this thread,
-testing, polishing, and finalizing APIs. We can do final
polish and formal specification, for sure. Y'all should do the hard
part, not because we are lazy but because you are many, closer to your
problem domains and use-cases, and collectively wiser about the details.
/be
Brendan Eich wrote
Tab Atkins Jr. wrote:
This works great as a general principle, but honestly tons of
languages have already forged this path. It's pretty straightforward,
I think.
I made the case for building it in sooner, but TC39 wanted less sooner
based on library usage. There was a minority position (as
Brendan Eich wrote:
'with' to whither away
Rats, my fingers betrayed my punning brain.
We could hope for 'with' to wither away. Or 'whith' to whither away.
Gonna pronounce `with` using voiced glottal fricative from now on.
/be
___
es-discuss
Not deprecated -- any reason you brought it up in the context of 'with'?
/be
John Barton wrote:
Is __proto__ deprecated by TC39? The spec says otherwise.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Isiah Meadows wrote:
Transitioning the native API to modules is more of a proposed long
term goal of this proposal. It'll take years to fully realize.
True, and I don't see a shortcut. Do you?
Having TC39 rush something designed by champions and ratified by
committee but without any
L2L 2L wrote:
I see the value of this, cause it denote not only the constructor, but what an
object is:
Object.getConstructorOf()//String
Object.getConstructorOf(0)//Number
Object.getConstructorOf(function(){})//Function
Object.getConstructorOf({})//Object
Object.getConstructorOf([]);//Array
Domenic Denicola wrote:
But requiring explicit initialization seems fine too.
So are you withdrawing your variation (option 3 or whatever it is)? Not
advocating, just asking (trying to keep up!).
Unless the head syntax camp rallies somehow, I'm convinced: option 2
Kevin Smith wrote:
Just for the sake of capturing everything, here's an updated version
of the extended header idea:
https://gist.github.com/zenparsing/5efa4459459b9f04d775
Cheers!
In the interest of the full dialectic, I encourage everyone tempted by
new^ and
Jussi Kalliokoski wrote:
Unicode flag disabling features to enable parallelism is another
footnote for WTFJS.
A bit overdone, but I agree on this point.
A separate flag per regexp, and/or a way to opt-out of RegExp.$foo
altogether, seem better.
/be
Allen Wirfs-Brock wrote:
A separate flag per regexp, and/or a way to opt-out of RegExp.$foo
altogether, seem better.
Speaking strictly from a standards perspective, it seems that we are getting a
bit ahead of ourselves.
Sure, but this is es-discuss, it runs ahead of standardization by
I agree with Domenic that any derived-class constructor that needs to
allocate with specific arguments *and* that must distinguish new'ing
from calling should have to write an if-else. That's a hard case, EIBTI,
etc.
(Allen: well-done on that aspect of the design, BTW. `new^` is growing
on
Allen Wirfs-Brock wrote:
actually I did respond:
Sorry, missed that message somehow. Sold!
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Allen Wirfs-Brock wrote:
We have long standing consensus on the current ES6 class design and
that includes a `super()` constructor call that can be arbitrarily
placed within the constructor body.
I'm ok with consensus if it's real and strong. We aren't there yet, and
AFAIK we never had
[Snipped text that talks mostly about what but not why.]
Allen Wirfs-Brock wrote:
But as you say, the real issue we are trying to address now is eliminating
exposure of uninitialized non-ordinary objects and support for constructors
called as functions. I think we're on a good path to solve
Alex Kocharin wrote:
What's the advantage of `re.test(str); RegExp.$1` over `let
m=re.match(str); m[1]`?
Right. I think Andrea is smoking something :-P.
I assume RegExp[$'] and RegExp[$`] are nice to have, I remember
them from perl, but never actually used them in javascript.
I regret
Herby Vojčík wrote:
This is probably not a constructive feedback, but thanks for changing
super semantics in constructors, as it's fixing the new/super
difference of previous design.
I remember your past posts:
Andreas Rossberg wrote:
Well, regarding this particular aspect, the wider curly braces family
doesn't have a consistent opinion. Our current design is following
Java more closely than C++, which I think is fine (modulo dubious
defaults). C++ needed the special syntax primarily because of its
Rick Waldron wrote:
The first is also objectionable because it breaks existing implicit
return semantics.
Say what? Constructors can return a different object from `this`, that's
just JS.
(Anyway the relevant comparison is verbosity of the proposal vs.
something implicit, not a more
Rick Waldron wrote:
On Mon, Sep 15, 2014 at 2:57 PM, Brendan Eich bren...@mozilla.org
mailto:bren...@mozilla.org wrote:
Rick Waldron wrote:
The first is also objectionable because it breaks existing
implicit return semantics.
Say what? Constructors can return
Allen Wirfs-Brock wrote:
On Sep 14, 2014, at 9:24 PM, Brendan Eich wrote:
perhaps: `constructor{a: x, b: y), [a1,a2,a3,...arest], c ) :
super(arguments[0], arguments[1]) {}` but that means that the
special header form must allow arbitrary expressions. Are those
expression
301 - 400 of 4618 matches
Mail list logo
