es-discuss Digest, Vol 131, Issue 29

Ranando King kingmph at gmail.com
Tue Jan 16 16:19:58 UTC 2018


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, <es-discuss-request at mozilla.org> wrote:

> Send es-discuss mailing list submissions to
>         es-discuss at mozilla.org
>
> 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
>         es-discuss-request at mozilla.org
>
> You can reach the person managing the list at
>         es-discuss-owner at mozilla.org
>
> 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 _ <oriol-bugzilla at hotmail.com>
> To: "es-discuss at mozilla.org" <es-discuss at mozilla.org>
> 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 <warcraftthreeft at sbcglobal.net>
> To: "Michał Wadas" <michalwadas at gmail.com>
> Cc: Es-discuss <es-discuss at mozilla.org>
> 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 <warcraftthreeft at sbcglobal.net>
> To: "Michał Wadas" <michalwadas at gmail.com>
> Cc: Es-discuss <es-discuss at mozilla.org>
> 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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180116/432e8a1d/attachment.html>


More information about the es-discuss mailing list