Already considered and to be implemented via strong mode IIRC.
On 18.03.2016 14:36, Brian Barnes wrote:
I know properties on classes are getting a look over for the next
iteration (last I checked) and I understand javascript is obviously a
different language then other oo languages with a
I feel like it should, or I am misunderstanding something fundamental. I
made a basic scenario to explain:
```js
var arrays = new WeakMap();
function ArrayView(array) {
arrays.set(this, array);
return new Proxy(this, {
set: (target, property, value) => (arrays.has(this) && property in
Try this... It will only seal if calling new. The subclasses will still
need to seal though.
```js
class Test {
constructor() {
this.x = 1;
if(new.target === Test) {
Object.seal(this);
}
}
}
```
On Fri, Mar 18, 2016 at 9:57 AM, Brian Barnes wrote:
>
Isiah Meadows wrote:
A polyfill could check if `A.p.sort` is stable, replacing if necessary, and
alias the old one to `A.p.fastSort` if it doesn't exist.
How does one check/test for the stability of a black-box sort? You
can't, afaik.
In my opinion, you'll never be able to rely on the
I'm trying to make the proxy-as-a-prototype pattern work but I've just
discovered the `ownKeys` trap is never called on traps on the prototype. So
even if the `has` trap is allowed to see the `receiver`, and thus verify
the properties "0", "1" exist, this pattern would fail to return the
On 3/17/16 11:42 AM, Leo Balter wrote:
The current website needs an update. If it makes less painful to run the
tests on a shell, you can try https://github.com/bterlson/eshost
I'm specifically looking for a harness that will run the tests in a web
worker, so I'm not sure that this helps
I know properties on classes are getting a look over for the next
iteration (last I checked) and I understand javascript is obviously a
different language then other oo languages with a different foundation,
but I bring this up for it's usage in producing stricter code that
reduces errors and
Another way that allowed you to use `new` on both base and derived
classes would be something like this:
```js
"use strict";
function sealInstance(bool) {
if (bool) {
Object.seal(this);
}
}
class Base {
x = 1;
constructor(seal = true) {
Ugh, well, I guess I typed a lot of stuff for nothing! And by the look
of their experiment, what I wanted was actually one of the major blockers.
It seems classes will really need a more standard type of syntax (non
static) before you could actually achieve this, and might be a bridge
too
How about an `Array.prototype.stableSort(comparator?)` method? Several
languages already have something like this, anyways.
(Speaking of bugs related to unstable sorts, my blog has that problem as
well - unstable sort resulting in incorrect order.)
On Wed, Mar 16, 2016, 18:50 Tab Atkins Jr.
I use:
http://v8.github.io/test262/website/default.html
Saam
> On Mar 17, 2016, at 6:31 AM, Boris Zbarsky wrote:
>
> It looks like there used to be a
> http://ie.microsoft.com/testdrive/HTML5/WebWorkerTest262/Default.html but
> it's gone.
>
> There also used to be a
AFAIK the reason there is a `receiver` is to deal with prototype cases ...
if that was a good enough reason to have one, every prototype case should
be considered for consistency sake.
We've been advocating prototypal inheritance for 20 years and now it's an
obstacle or "not how JS is"?
```js
You can accomplish this by calling `Object.seal(this)` in the constructor.
```js
constructor() {
this.x = 1;
Object.seal(this);
}
```
On Fri, Mar 18, 2016 at 8:36 AM, Brian Barnes wrote:
> I know properties on classes are getting a look over for the next
> iteration
Why should you have to opt into to stable sort? Why not the other way
around? `Array.prototype.fastestSort` or some such -- or better yet, spec a
symbol for it that falls back to `Array.prototype.sort` for implementations
that don't expose a faster unstable variety.
On Thu, Mar 17, 2016 at 7:35
It looks like there used to be a
http://ie.microsoft.com/testdrive/HTML5/WebWorkerTest262/Default.html
but it's gone.
There also used to be a http://test262.ecmascript.org/ (linked from
various places on the ecmascript.org wiki) but that's gone too.
Does anyone know whether this test is
>
> Although it is more work for the person writing code, I believe having
> to explicitly use keywords (await or yield) in function bodies makes
> it very clear what is happening, and ultimately leads to better code
> with less potential for human error in the long run.
> ...
> The beauty of
Note that this does prevent extensions, but will only throw in strict
mode. In sloppy mode, the assignment will silently fail.
On 18.03.2016 15:07, Michael Theriot wrote:
You can accomplish this by calling `Object.seal(this)` in the constructor.
```js
constructor() {
this.x = 1;
Bradley, looks like you have a typo and should be using the `this` argument
you pass to `exec` rather than `this` in the arrow?
```
class B extends A {
constructor() {
super(inst => {
inst.b = 2;
});
}
}
```
On Fri, Mar 18, 2016 at 8:27 AM, Bradley Meck
I agree with Allen. I am certainly willing -- often eager -- to revisit and
revise old design decisions that are considered done, when I think the cost
of leaving it alone exceeds the cost of changing it. In this case, the
arguments that this extra parameter would be an improvement seem weak. Even
2016-03-19 0:15 GMT+01:00 Michael Theriot :
> To be clear, I'm not suggesting behavior like `getOwnPropertyNames` be
> overridden by anything on the prototype, just a way to use proxies without
> having to instantiate identical copies that all use the same handler.
I'm mostly neutral on this, other than that a stable sort API should exist,
and it shouldn't involve changing how the first argument of
`Array.prototype.sort` is processed.
On Thu, Mar 17, 2016, 22:20 Bergi wrote:
> Isiah Meadows wrote:
>
> > A polyfill could check if
The effect addition to try-catch seems like some sort of hacky
workaround, that would get the job done, but then would make try-catch
be used for purposes other than catching errors, which defeats it's
original purpose. I think it's important to keep that error-based
meaning and not mix it with
>
> Michael’s preferred approach also introduces observable irregularity into
> the standard JS inheritance model for ordinary objects.
> Consider an object created using Michael’s preferred approach:
> ```js
> var arr = [0, 1];
> console.log(Reflect.has(arr,”0”)); //true, arr has “0” as an own
Agreed with everybody else the `receiver` is always needed and `Proxy` on
the prototype makes way more sense than per instance.
Also the `getPrototypeOf` trap is really pointless right now
```js
function Yak() {}
Yak.prototype = new Proxy(Yak.prototype, {
getPrototypeOf: (target) =>
Brian, Your first example isn't too far from ES2017. Leave away the
`let`s and seal it, and you got:
```js
"use strict";
class Test {
x = 1;
y = 2;
constructor() {
Object.seal(this);
this.z = 3; // TypeError
}
}
```
You can already use this using transpilers (at
25 matches
Mail list logo