Subject: Re: Proposal: Optional Static Typing (Part 3)

Ranando King kingmph at gmail.com
Tue Jan 16 23:06:27 UTC 2018


One day I'm going to get used to the quirks of using this mailing list
through gmail... Just changing the subject back....

On Tue, Jan 16, 2018 at 2:33 PM, <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: es-discuss Digest, Vol 131, Issue 29 (Ranando King)
>    2. Re: Proposal: Optional Static Typing (Part 3) (Isiah Meadows)
>
>
> ---------- Forwarded message ----------
> From: Ranando King <kingmph at gmail.com>
> To: es-discuss <es-discuss at mozilla.org>
> Cc:
> Bcc:
> Date: Tue, 16 Jan 2018 10:19:58 -0600
> Subject: Re: es-discuss Digest, Vol 131, Issue 29
> 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
>>
>>
>
>
> ---------- Forwarded message ----------
> From: Isiah Meadows <isiahmeadows at gmail.com>
> To: kai zhu <kaizhu256 at gmail.com>
> Cc: Brandon Andrews <warcraftthreeft at sbcglobal.net>, "
> es-discuss at mozilla.org" <es-discuss at mozilla.org>
> Bcc:
> Date: Tue, 16 Jan 2018 15:32:36 -0500
> Subject: Re: Proposal: Optional Static Typing (Part 3)
> Inline.
>
> -----
>
> Isiah Meadows
> me at isiahmeadows.com
>
> Looking for web consulting? Or a new website?
> Send me an email and we can get started.
> www.isiahmeadows.com
>
> On Tue, Jan 16, 2018 at 7:44 AM, kai zhu <kaizhu256 at gmail.com> wrote:
> >
> > more ranting.
> > tldr - javascript-programmers are more productive spending their
> limited-time documenting and writing validation-code for endpoint-level
> rest-apis instead of for code-level business-logic (swagger/openapi is more
> useful than OST/flow/typescript).
> >
> > i'm generally a javascript-architecture skeptic.  from my experience in
> industry, there is zero-correlation between careful architecting (*cough*
> bikeshedding) and successfully getting over the javascript-integration hump
> to ship a product
>
> I only partially agree. For most smaller things, and even some
> mid-sized projects (e.g. simple DB servers with REST APIs), all you
> really need to architect is your API, and the rest will largely fall
> out naturally. The front and back end are probably equal in this.
>
> > the “best" architecture/design for any given web-project is whatever
> ad-hoc hacks/rewrites/fire-fighting it takes to get you past the
> integration-stage [...]
>
> If it doesn't include a lot of business logic in JS, then sure. I can
> tell you my blog, which includes mostly hand-written JS, is a big ball
> of mud on the front end. But it works.
>
> > [...] (and javascript-fatigue is partly the realization from naive
> newcomers that you almost always end up with spaghetti-code after
> integration, no matter how hard you fight it).
>
> Disagree here, particularly on the meaning of "JavaScript fatigue".
> That phrase came to be not because of anything about what frameworks
> do to your code, but from:
>
> 1. The fact that build systems are/were getting unnecessarily complex.
> For some communities (React in particular was notorious), it may take
> setting up 10+ modules independently, each with non-trivial
> configuration, just to get started on the simple stuff.
> 2. The ecosystem at large was, and still is, churning at such a fast
> rate that people were struggling to keep track of it all, and
> consequently had issues adjusting to it. React's community was also a
> notorious offender for iterating too quickly, but that is at least
> starting to settle down.
>
> Neither of these actually directly relate to the code quality
> underneath, and even those who enjoyed the frameworks/libraries
> themselves were getting tired and stressed over trying to keep up with
> everything.
>
> > it might be different at microsoft/facebook/google, but their abnormal
> tooling environments (and resulting skewed world-view of javascript) are
> hardly representative of the industry as a whole.
>
> First, could you please quit assuming that those companies are the
> primary users of things like TypeScript/etc.? I could understand Flow
> being very specific to Facebook (it's rarely used outside of Facebook
> and React apps), but TypeScript, not so much - it's the 9th most
> popular language according to Stack Overflow's most recent Developer
> Survey. [1] At this point, it's about as popular as Ruby, according to
> the survey's participants, and there's *no* way that the combination
> of the three could account for any more than a small minority of the
> participants:
>
> - Microsoft developed TypeScript, and has been using it for a while -
> this is probably a given.
> - Facebook almost exclusively uses Flow - you could've probably guessed
> this.
> - Google internally relies primarily on either GWT (Java to JS) or the
> Closure Compiler (uses JSDoc for types) for type checking, and only
> last year started allowing unrestricted development using TypeScript.
> [2]
>
> So the only corporation that could substantially contribute directly
> to TypeScript's dominance would be Microsoft, and Google's influence
> is more indirect (they use Angular, which bases its entire ecosystem
> on TypeScript, but they aren't one of Angular's primary users).
>
> Second, those three aren't even primary users of even Webpack. In
> fact, two of Webpack's biggest backers are Adobe and Capital One (yes,
> that financial company), each having given $12K to that OSS project.
> [3]
>
> [1]: https://insights.stackoverflow.com/survey/2017#
> most-popular-technologies
> [2]: https://news.dartlang.org/2017/04/dart-typescript-and-
> official-languages.html
> [3]: https://webpack.js.org/
>
> >
> > what does correlate with successfully shipping a product, is having
> well-documented endpoint rest-apis, so the frontend-folks aren’t completely
> clueless during integration when they try talking to the backend, and it
> doesn’t respond or timeout for some reason.  a web-project has a higher
> chance of shipping successfully if you spend your limited engineering-time
> doing integration-level documentation and validation-checking (using
> swagger as shown in following screenshots) instead of code-level OST which
> nobody talking to your server during integration cares about:
>
> Yes, if you're dealing mostly with clients as a freelancer or
> small-time developer. If you're rolling your own data-driven business
> or complex web app, types become invaluable. There's a key difference
> between doing things for clients with much smaller needs, and doing
> things for your own high-tech business. I have experience in both, and
> I can assure you, there's a whole world of difference between the two.
> For one, ugly hacks work in one-off projects, but not for anything you
> have to sustain and put substantial amounts of time to maintain.
>
> >
> > (these screenshots are from real-world endpoint rest-apis that have been
> documented with integration-level type-checking using swagger -
> https://kaizhu256.github.io/node-swgg-google-maps/build..
> beta..travis-ci.org/app/)
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Jan 11, 2018, at 10:01 PM, Isiah Meadows <isiahmeadows at gmail.com>
> wrote:
> >
> > From a quick read, I'm more in favor of something that's a little more
> restricted to start, something like what Python has. Python has optional
> static type annotations, but the Python interpreter just ignores them. They
> are present purely for the purposes of tooling, and are silently ignored at
> runtime.
> >
> > Conversely, PHP took a similar approach and initially also made it
> cosmetic to start, only later taking advantage of *some* type annotations
> by adding runtime behavior to some of the simpler ones (like primitives).
> >
> > One of the reasons why I'd prefer a simpler approach to start is that
> TypeScript and Flow, the two main implementations that add syntax, have a
> *very* similar syntax, but have several nuances that would make a heavier
> proposal much harder to accomplish:
> >
> > - Flow has `?Foo` for optional types, TypeScript just uses unions.
> > - TypeScript has mapped/index types, where Flow uses special named types.
> > - Flow allows omitted parameter names in function types, TypeScript only
> allows named parameters with implicit `any` types.
> > - Flow has exact types, TypeScript doesn't.
> > - Flow has `opaque type`, TypeScript only has `type`.
> > - Flow constrains with `T: Super`, TypeScript uses `T extends Super`.
> > - Flow has 3 different ways of importing bindings a module (depending on
> what's being imported), TypeScript only has one.
> > - Flow has existential types, TypeScript doesn't.
> >
> > Also, both TypeScript and Flow are still working out how to properly
> type some of the more advanced JS (like variadic functions and auto-curried
> functions), so their syntax is *still* not exactly stable enough I'd feel
> comfortable encoding much into the spec. (They do have a stable core,
> though.)
> >
> > One other thing is that multiple active proposals could end up requiring
> TS and/or Flow to substantially change parts of their syntax, including:
> >
> > - Private [fields][1] and [methods][2] (stage 3 and 2 respectively,
> affects TS)
> > - [First class protocols][3] (stage 1, affects both TS and Flow)
> > - [Typed literals][4] (stage 1, affects TS mostly)
> >
> > [1]: https://github.com/tc39/proposal-class-fields
> > [2]: http://github.com/tc39/proposal-static-class-features/
> > [3]: https://github.com/michaelficarra/proposal-first-class-protocols
> > [4]: https://github.com/mikewest/tc39-proposal-literals
> >
> > -----
> >
> > Isiah Meadows
> > me at isiahmeadows.com
> >
> > Looking for web consulting? Or a new website?
> > Send me an email and we can get started.
> > www.isiahmeadows.com
> >
> > On Thu, Jan 11, 2018 at 3:09 AM, Pranay Prakash <pranay.gp at gmail.com>
> wrote:
> >>
> >> I'm still yet to read the entire proposal, but with a quick skim, it
> seems to me like this is essentially what Typescript or Flow offers you:
> i.e. an opt-in type system?
> >>
> >> I'm wondering if you have any good reasons to want there to be a
> standardised static type annotation syntax within ECMAScript instead of a
> "Bring Your Own Type Checker" system.
> >> If you do have some thoughts on this, you might also want to include
> that as a preface on your Github's README.You have a "Rationale" bit that
> seems to ignore the existence of these existing systems.
> >>
> >> Waiting to hear more thoughts on this :)
> >>
> >> On Thu, 11 Jan 2018 at 11:56 Brandon Andrews <
> warcraftthreeft at sbcglobal.net> wrote:
> >>>
> >>> It's been a year and a half since my last post and I've made a number
> of small changes and corrections over 2.5 years. The proposal is still on
> my github at:
> >>>
> >>>
> >>> https://github.com/sirisian/ecmascript-types
> >>>
> >>> I've talked to a lot of people about it, but I haven't gotten much
> criticism or suggested improvements. I'm a bit in over my head in trying to
> flesh out all the details or all the nuanced syntax changes that a
> championed proposal would be expected to do. That said I've been making
> more changes lately to try to find edge cases and potential problems.
> >>>
> >>>
> >>> I've been jotting down issues here: https://github.com/sirisian/
> ecmascript-types/issues I closed a number of them recently as I made
> changes.
> >>>
> >>> If anyone has any comments on what I should expand, look into more, or
> change I'm open to discussing them here or on github.
> >>>
> >>> One issue in particular is this: https://github.com/sirisian/
> ecmascript-types/issues/15 It covers whether I should introduce a new
> assignment operator to my proposal. Maybe there's another way to look at it
> or a different solution. I need fresh eyes on the whole proposal really to
> get a list of new issues to tackle this year.
> >>>
> >>> I'm also not against having one or multiple people champion it and
> working on it without me. (I haven't been able to dedicate time to read the
> ECMAScript spec and really understanding the grammar fully so having
> someone qualified to take over would help the proposal a lot).
> >>>
> >>>
> >>> Thanks for reading the proposal for anyone that has the time.
> >>> _______________________________________________
> >>> es-discuss mailing list
> >>> es-discuss at mozilla.org
> >>> https://mail.mozilla.org/listinfo/es-discuss
> >>
> >>
> >> _______________________________________________
> >> es-discuss mailing list
> >> es-discuss at mozilla.org
> >> https://mail.mozilla.org/listinfo/es-discuss
> >>
> >
> > _______________________________________________
> > es-discuss mailing list
> > es-discuss at mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
> >
>
>
> _______________________________________________
> 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/cdf957ae/attachment-0001.html>


More information about the es-discuss mailing list