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
On Wed, Sep 17, 2014 at 8:35 AM, Steve Fink sph...@gmail.com wrote:
On 09/16/2014 10:13 PM, Jussi Kalliokoski wrote:
On Wed, Sep 17, 2014 at 3:21 AM, Alex Kocharin a...@kocharin.ru wrote:
What's the advantage of `re.test(str); RegExp.$1` over `let
m=re.match(str); m[1]`?
Nothing.
On Wed, Sep 17, 2014 at 6:35 AM, Steve Fink sph...@gmail.com wrote:
Is
if ((m = /foo:(\d+)/.exec(str)) parseInt(m[1], 10) 15) { ... }
so bad?
well, you just polluted the global scope by accident creating (maybe) a
hybrid Array with properties attaches in order to just access index 1
you could obtain that inside a `with` statement :P
```js
with(RegExp) {
if (/r(\d)d(\d)/i.test('R2D2')) {
'22' === $1 + $2;
}
}
```
Regards
On Wed, Sep 17, 2014 at 8:56 AM, Jussi Kalliokoski
jussi.kallioko...@gmail.com wrote:
On Wed, Sep 17, 2014 at 8:35 AM, Steve Fink
Le 15 sept. 2014 à 23:19, Kevin Smith zenpars...@gmail.com a écrit :
Isn't the latter (since it specifies : super(x)) actually identical to
constructor(x, y) {
this = new super();
this.y = y;
}
IOW, isn't it I am constructor only and will throw if
I find the new suggestions hard to make sense of and the current approach quite
elegant:
```
Foo[[Construct]](arg) ::=
1. let obj = Foo[@@create]()
2. Foo.call(obj, arg)
```
To me, it seems that this is how things should work internally, because that’s
what’s actually going on. Is
I agree, the thread was about defaults when no super call is present.
Allen Wirfs-Brock al...@wirfs-brock.comnapísal/a:
Unfortunately, I think the super in function header discussion is mostly a
distraction and not really helping focus the discussion on the core issues.
Allen
Claude Pache claude.pa...@gmail.comnapísal/a:
For instance, if I wanted to support to be called through the legacy
`SuperConstructor.call(this, ...args)` trick in addition to be new’d, I'd
rather try the following:
constructor(x, y) {
if (new^)
this = new super(x);
constructor(x, y) {
if (new^)
this = new super(x);
else
super.constructor(x);
this.y = y;
}
The point here is that the purpose of the constructor method is not only
allocation, but also (and primarily) initialisation.
Yes - you
On Sep 17, 2014, at 6:40, Kevin Smith
zenpars...@gmail.commailto:zenpars...@gmail.com wrote:
constructor(x, y) {
if (new^)
this = new super(x);
else
super.constructor(x);
this.y = y;
}
The point here is that the purpose of the
That seems fine. Enabling different behaviour for called vs. constructed
should only be used to explain the builtins; user code should not do so
themselves. So it makes sense to me that those trying to do that would get
punished with having to type more.
Yes, but if we guide users toward
On Sep 17, 2014, at 7:10, Kevin Smith
zenpars...@gmail.commailto:zenpars...@gmail.com wrote:
That seems fine. Enabling different behaviour for called vs. constructed should
only be used to explain the builtins; user code should not do so themselves. So
it makes sense to me that those trying
That's not true, is it? Assuming someone (e.g. B) actually assigns a
property of `this`, an error will occur (or worse, a global will be
created, in sloppy mode).
Sorry, when I say called, I mean called with a proper this variable.
Under the current system, constructors work as this
17.09.2014, 18:10, "Kevin Smith" zenpars...@gmail.com: That seems fine. Enabling different behaviour for called vs. constructed should only be used to explain the builtins; user code should not do so themselves. So it makes sense to me that those trying to do that would get "punished" with
Domenic Denicola wrote:
On Sep 17, 2014, at 7:10, Kevin Smith zenpars...@gmail.com
mailto:zenpars...@gmail.com wrote:
That seems fine. Enabling different behaviour for called vs.
constructed should only be used to explain the builtins; user
code should not do so themselves.
Le 11 sept. 2014 à 18:35, Allen Wirfs-Brock al...@wirfs-brock.com a écrit :
These two Gist have parallel construction for easy comparison. I suggest
approaching this is by first readying through one of the Gists and then doing
a side by side read through of the alternative to see the
On Wed, Sep 17, 2014 at 9:59 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
On Sep 17, 2014, at 6:40, Kevin Smith zenpars...@gmail.com wrote:
constructor(x, y) {
if (new^)
this = new super(x);
else
super.constructor(x);
On Sep 16, 2014, at 11:22 PM, Brendan Eich wrote:
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,
On Tue, Sep 16, 2014 at 8:16 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
I also noticed today that the static `RegExp` properties are not specced,
which seems at odds with our new mandate to at least Annex B-ify the
required-for-web-compat stuff.
As a general note to people
On Wed, Sep 17, 2014 at 11:39 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
Annex B contains many changes to RegExp from the base standard. Perhaps a
better way to approach this is to have a standard (not Annex B) regexp flag
(perhaps 's', for standard or strict) that means that this
FWIW that 's' flag would work for me, but about not being specd, those
properties are described already here:
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-getreplacesubstitution
and these are a long time de-facto standard. somebody wrote already about
them a while ago:
On Sep 17, 2014, at 8:59 AM, Andrea Giammarchi wrote:
FWIW that 's' flag would work for me, but about not being specd, those
properties are described already here:
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-getreplacesubstitution
that doesn't say anything about RegExp
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
On 17 September 2014 19:04, Brendan Eich bren...@mozilla.org wrote:
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.
I agree.
On 9/17/14, 1:15 PM, Andreas Rossberg wrote:
In the light of that, I'm stilling missing the
compelling reason to introduce new^ at all.
Say you have:
class A extends B {
constructor() {
this = new super();
}
};
class B {
constructor() {
// what here?
}
};
Regarding:
... My
understanding was that there is wide agreement that invoking
constructors without 'new' should be discouraged, and that functions
behaving differently for Call and Construct are considered a legacy
anti-pattern...
I AGREE
I don't know all the story and forces to keep
On Sep 16, 2014, at 4:55 PM, Brendan Eich wrote:
...
It would help, I think, if you replied to Kevin's mail dated 12:05pm
yesterday, which ended:
Well, what I'm trying to point out is that it's always an error to set this
if new^ is undefined. So it's kind of strange to force the
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
On Sep 17, 2014, at 6:17 AM, Herby Vojčík wrote:
Claude Pache claude.pa...@gmail.comnapísal/a:
For instance, if I wanted to support to be called through the legacy
`SuperConstructor.call(this, ...args)` trick in addition to be new’d, I'd
rather try the following:
I still feel like Kevin's point has not yet been resolved. How can we make
this work with today's patterns?
import {C} from './C.js';
function D() {
C.call(this);
}
D.prototype = {
__proto__: C.prototype,
constructor: D,
...
}
Now assume that C.js initially used the ES5 pattern above
On Sep 17, 2014, at 6:39 AM, Kevin Smith wrote:
constructor(x, y) {
if (new^)
this = new super(x);
else
super.constructor(x);
this.y = y;
}
The point here is that the purpose of the constructor method is not only
allocation,
On Sep 17, 2014, at 7:24 AM, Kevin Smith wrote:
That's not true, is it? Assuming someone (e.g. B) actually assigns a property
of `this`, an error will occur (or worse, a global will be created, in sloppy
mode).
Sorry, when I say called, I mean called with a proper this variable.
On Sep 17, 2014, at 7:29 AM, Claude Pache wrote:
Le 11 sept. 2014 à 18:35, Allen Wirfs-Brock al...@wirfs-brock.com a écrit :
These two Gist have parallel construction for easy comparison. I suggest
approaching this is by first readying through one of the Gists and then
doing a side
On Sep 17, 2014, at 10:15 AM, Andreas Rossberg wrote:
On 17 September 2014 19:04, Brendan Eich bren...@mozilla.org wrote:
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
On Sep 17, 2014, at 10:50 AM, Erik Arvidsson wrote:
I still feel like Kevin's point has not yet been resolved. How can we make
this work with today's patterns?
import {C} from './C.js';
function D() {
C.call(this);
}
D.prototype = {
__proto__: C.prototype,
constructor: D,
I meant nothing new to learn, it doesn't say anything but it describes
them already so when you say not in spec I think well, not as property,
even if every engine has them, but already in specs somehow.
Hence a reason to not break de-facto legacy and think about an opt out
instead
Regards
On
Correction below: s/this\^/new\^/
On Sep 17, 2014, at 12:19 PM, Allen Wirfs-Brock wrote:
On Sep 17, 2014, at 10:50 AM, Erik Arvidsson wrote:
I still feel like Kevin's point has not yet been resolved. How can we make
this work with today's patterns?
import {C} from './C.js';
`Object.freeze` do not solve the issue with WeakMap, right?
( http://wiki.ecmascript.org/doku.php?id=strawman:value_objects )
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
`lastIndex` also prevents usage of one instance in parallel...
I know the javascript do not support parallel execution, but the code is not so
beatiful...
the idea to deprecate lastIndex was proposed 4 years ago:
see
http://blog.stevenlevithan.com/archives/fixing-javascript-regexp
40 matches
Mail list logo
