Your statements are no less true for the essential internal methods than they are for the traps of a [[ProxyHandler]]. That's my point. This work is already being done using the internal methods. I'm just asking that where calls to internal methods exist, if the object on which the call was made is a Proxy, then all calls to the internal methods need to be made via the [[ProxyHandler]] of that Proxy object. None of the storage requirements to validate the invariants will change.
On Tue, Jan 16, 2018 at 6:00 AM, <[email protected]> wrote: > Send es-discuss mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.mozilla.org/listinfo/es-discuss > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of es-discuss digest..." > > Today's Topics: > > 1. Re: An idea to extend the functionality of Proxy objects. > (Oriol _) > 2. Re: Proposal: Optional Static Typing (Part 3) (Brandon Andrews) > 3. Re: Proposal: Optional Static Typing (Part 3) (Brandon Andrews) > > > ---------- Forwarded message ---------- > From: Oriol _ <[email protected]> > To: "[email protected]" <[email protected]> > Cc: > Bcc: > Date: Mon, 15 Jan 2018 16:38:39 +0000 > Subject: Re: An idea to extend the functionality of Proxy objects. > The problem is enforcing the invariants. For example, if > [[GetOwnProperty]] returns a non-configurable non-writable descriptor, then > all future calls must also return a non-configurable non-writable > descriptor with the same value. But you can't check this by just calling > some traps. Instead, you need to store the property value value somewhere > so that you can compare in all future calls. And the target object is the > perfect place to store it. > > If the invariants prevent your traps from behaving like you want, just use > an extensible object with no non-configurable property as the target. > > - Oriol > > > > ---------- Forwarded message ---------- > From: Brandon Andrews <[email protected]> > To: "Michał Wadas" <[email protected]> > Cc: Es-discuss <[email protected]> > Bcc: > Date: Tue, 16 Jan 2018 00:46:06 +0000 (UTC) > Subject: Re: Proposal: Optional Static Typing (Part 3) > >> Part of this has had me considering if freezing classes (and all > recursively referenced types) used in the type system is viable. > > > ```js > function foo(bar: Array.<Set>) > { > // whatever > } > [Array, Set] = [Set, Array]; > foo(new Array([Set()])); > ``` > > > You can't freeze all builtins for obvious reasons. > > > I'm out of ideas. Do you or anyone here see a way to get around such an > issue? > > > You totally omitted point that your type system can't use or describe > this function: > > > ```js > function issue(Ctor) > { > assert(Reflect.isConstructor(Ctor)); // Type system don't provide > way to disguintish object with [[Construct]] and [[Call]] methods. > assert(Foo.isPrototypeOf(Ctor)); // Type system don't provide way > to ensure prototypal inheritance > > const retClass = class extends Ctor // Type system don't provide > way to describe types being returned from function > { > }; > Object.assign(retClass.prototype, mixin); // Object.assign can be > overridden to do anything, so actual code execution is required to prove > it's valid > return retClass; > } > ``` > > Just to be clear. Is Ctor a type? Like "class Ctor extends Foo {}" or an > instance? If it's a Type it might be better handled with generics later > like: > > ```js > function issue<Ctor extends Foo>(mixin) > { > const retClass = class extends Ctor > { > }; > Object.assign(retClass.prototype, mixin); > return retClass; > } > ``` > > I hope I understood the requirements. Is it necessary to allow the type > system to handle passing types as arguments? Do other languages allow this? > > ```js > assert(Reflect.isConstructor(Ctor)); // Type system don't provide way to > disguintish object with [[Construct]] and [[Call]] methods. > ``` > > So you'd expect a language feature like an interface that mandates a > constructor or something more general like "this object is a class"? > > ```js > assert(Foo.isPrototypeOf(Ctor)); // Type system don't provide way to > ensure prototypal inheritance > ``` > > So I should explicitly state that derived classes can be passed to > parameters typed with their super like most languages allow like: > > ```js > class A {} > class B extends A {} > function f(a:A) {} > f(new B()); // Valid > ``` > > In your example: > > ```js > function issue(Ctor:Foo):Foo > { > } > class A {} > // issue(new A()); // TypeError, A must be type Foo or extended from Foo > ``` > > Is that sufficient? > > ```js > const retClass = class extends Ctor // Type system don't provide way to > describe types being returned from function > { > }; > ``` > > Would this be asking for interfaces and structural matching like in > TypeScript? I left it out originally to simplify the proposal with the > expectation it would be added in later. Do you see this more as a mandatory > feature? "any" can be used in the meantime unless I'm mistaken. (I should > probably add a section in the proposal covering this). > > > > ---------- Forwarded message ---------- > From: Brandon Andrews <[email protected]> > To: "Michał Wadas" <[email protected]> > Cc: Es-discuss <[email protected]> > Bcc: > Date: Tue, 16 Jan 2018 09:34:44 +0000 (UTC) > Subject: Re: Proposal: Optional Static Typing (Part 3) > Some follow-up as I think more about this. > > > > You can't freeze all builtins for obvious reasons. > > > I'm getting that the reason for not freezing them would be to define > extensions? Could they not be defined and then frozen? I get that doesn't > stop them from being dynamic still. > > > The ability to change the built ins like Object causes a number of issues > as it makes all classes dynamic and your destructuring swap shows that > well. It seems like as long as Object can be modified everything has to use > run-time checking. > > > If Object could be made non-dynamic - froze it and made it const (or > equivalent) - then one could write: > > > ```js > const f = function(a:A) > { > a.x = 0; > } > const A = new class > { > x:uint8 = 5; // Object.defineProperty(A.prototype, 'x', { type: > uint8, writable: true, value: 5 }); (I think, might have to think about > this again, been a while). > } > f(new A()); // A is dynamic and the interpreter is forced to use a > run-time check. > > Object.freeze(A); // A is both const and frozen making it no longer > dynamic? If the dynamicness was removed then the engine could search the > code/AST and optimize f doing essentially a compile-time check at that point > > f(new A()); // Compile-time verification for all instances of f where the > argument is typed or the type can be inferred. > ``` > > > This usage of const works at global scope, but I feel like I'm missing > something that would undermine this. Like without real namespace support > this won't work well for some libraries. The syntax is also wordy and > confusing. One could add const class A {} modifiers, but that's still > confusing since codebases would be filled with it. > > > Also expecting users to freeze their classes to allow the interpreter and > JIT to function sanely is asking a lot. > > > One problem that keeps bothering me is this delayed freezing doesn't help > tooling. A class could be created, properties added in a complex operation, > then the class frozen later. The tooling would be blind to all these > changes. > > > I'm probably just barely touching the surface of issues. Anything I'm > overlooking? > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
