<div dir="ltr">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.</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 16, 2018 at 6:00 AM,  <span dir="ltr"><<a href="mailto:es-discuss-request@mozilla.org" target="_blank">es-discuss-request@mozilla.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send es-discuss mailing list submissions to<br>
        <a href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
        <a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/<wbr>listinfo/es-discuss</a><br>
or, via email, send a message with subject or body 'help' to<br>
        <a href="mailto:es-discuss-request@mozilla.org">es-discuss-request@mozilla.org</a><br>
<br>
You can reach the person managing the list at<br>
        <a href="mailto:es-discuss-owner@mozilla.org">es-discuss-owner@mozilla.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of es-discuss digest..."<br>
<br>Today's Topics:<br>
<br>
   1. Re: An idea to extend the functionality of Proxy objects.<br>
      (Oriol _)<br>
   2. Re: Proposal: Optional Static Typing (Part 3) (Brandon Andrews)<br>
   3. Re: Proposal: Optional Static Typing (Part 3) (Brandon Andrews)<br>
<br><br>---------- Forwarded message ----------<br>From: Oriol _ <<a href="mailto:oriol-bugzilla@hotmail.com">oriol-bugzilla@hotmail.com</a>><br>To: "<a href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a>" <<a href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a>><br>Cc: <br>Bcc: <br>Date: Mon, 15 Jan 2018 16:38:39 +0000<br>Subject: Re: An idea to extend the functionality of Proxy objects.<br>




<div dir="ltr">
<div id="m_3205288611950311294divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif" dir="ltr">
<div>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.<br>
<br>
If the invariants prevent your traps from behaving like you want, just use an extensible object with no non-configurable property as the target.<br>
<br>
- Oriol</div>
<br>
</div>
</div>

<br><br>---------- Forwarded message ----------<br>From: Brandon Andrews <<a href="mailto:warcraftthreeft@sbcglobal.net">warcraftthreeft@sbcglobal.net</a>><br>To: "Michał Wadas" <<a href="mailto:michalwadas@gmail.com">michalwadas@gmail.com</a>><br>Cc: Es-discuss <<a href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a>><br>Bcc: <br>Date: Tue, 16 Jan 2018 00:46:06 +0000 (UTC)<br>Subject: Re: Proposal: Optional Static Typing (Part 3)<br>>> Part of this has had me considering if freezing classes (and all recursively referenced types) used in the type system is viable.<br>
<br>
<br>
```js<br>
function foo(bar: Array.<Set>)<br>
{<br>
// whatever<br>
}<br>
[Array, Set] = [Set, Array];<br>
foo(new Array([Set()]));<br>
```<br>
<br>
> You can't freeze all builtins for obvious reasons.<br>
<br>
<br>
I'm out of ideas. Do you or anyone here see a way to get around such an issue?<br>
<br>
> You totally omitted point that your type system can't use or describe this function:<br>
<br>
<br>
```js<br>
function issue(Ctor)<br>
{<br>
        assert(Reflect.isConstructor(<wbr>Ctor)); // Type system don't provide way to disguintish object with [[Construct]] and [[Call]] methods.<br>
        assert(Foo.isPrototypeOf(Ctor)<wbr>); // Type system don't provide way to ensure prototypal inheritance<br>
<br>
        const retClass = class extends Ctor // Type system don't provide way to describe types being returned from function<br>
        {<br>
        };<br>
        Object.assign(retClass.<wbr>prototype, mixin); // Object.assign can be overridden to do anything, so actual code execution is required to prove it's valid<br>
        return retClass;<br>
}<br>
```<br>
<br>
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:<br>
<br>
```js<br>
function issue<Ctor extends Foo>(mixin)<br>
{<br>
        const retClass = class extends Ctor<br>
        {<br>
        };<br>
        Object.assign(retClass.<wbr>prototype, mixin);<br>
        return retClass;<br>
}<br>
```<br>
<br>
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?<br>
<br>
```js<br>
assert(Reflect.isConstructor(<wbr>Ctor)); // Type system don't provide way to disguintish object with [[Construct]] and [[Call]] methods.<br>
```<br>
<br>
So you'd expect a language feature like an interface that mandates a constructor or something more general like "this object is a class"?<br>
<br>
```js<br>
assert(Foo.isPrototypeOf(Ctor)<wbr>); // Type system don't provide way to ensure prototypal inheritance<br>
```<br>
<br>
So I should explicitly state that derived classes can be passed to parameters typed with their super like most languages allow like:<br>
<br>
```js<br>
class A {}<br>
class B extends A {}<br>
function f(a:A) {}<br>
f(new B()); // Valid<br>
```<br>
<br>
In your example:<br>
<br>
```js<br>
function issue(Ctor:Foo):Foo<br>
{<br>
}<br>
class A {}<br>
// issue(new A()); // TypeError, A must be type Foo or extended from Foo<br>
```<br>
<br>
Is that sufficient?<br>
<br>
```js<br>
const retClass = class extends Ctor // Type system don't provide way to describe types being returned from function<br>
{<br>
};<br>
```<br>
<br>
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).<br>
<br>
<br><br>---------- Forwarded message ----------<br>From: Brandon Andrews <<a href="mailto:warcraftthreeft@sbcglobal.net">warcraftthreeft@sbcglobal.net</a>><br>To: "Michał Wadas" <<a href="mailto:michalwadas@gmail.com">michalwadas@gmail.com</a>><br>Cc: Es-discuss <<a href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a>><br>Bcc: <br>Date: Tue, 16 Jan 2018 09:34:44 +0000 (UTC)<br>Subject: Re: Proposal: Optional Static Typing (Part 3)<br>Some follow-up as I think more about this.<br>
<br>
<br>
> You can't freeze all builtins for obvious reasons.<br>
<br>
<br>
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.<br>
<br>
<br>
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.<br>
<br>
<br>
If Object could be made non-dynamic - froze it and made it const (or equivalent) - then one could write:<br>
<br>
<br>
```js<br>
const f = function(a:A)<br>
{<br>
        a.x = 0;<br>
}<br>
const A = new class<br>
{<br>
        x:uint8 = 5; // Object.defineProperty(A.<wbr>prototype, 'x', { type: uint8, writable: true, value: 5 }); (I think, might have to think about this again, been a while).<br>
}<br>
f(new A()); // A is dynamic and the interpreter is forced to use a run-time check.<br>
<br>
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<br>
<br>
f(new A()); // Compile-time verification for all instances of f where the argument is typed or the type can be inferred.<br>
```<br>
<br>
<br>
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.<br>
<br>
<br>
Also expecting users to freeze their classes to allow the interpreter and JIT to function sanely is asking a lot.<br>
<br>
<br>
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.<br>
<br>
<br>
I'm probably just barely touching the surface of issues. Anything I'm overlooking?<br>
<br>
<br>______________________________<wbr>_________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/<wbr>listinfo/es-discuss</a><br>
<br></blockquote></div><br></div>