One day I'm going to get used to the quirks of using this mailing list
through gmail... Just changing the subject back....
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>
One day I'm going to get used to the quirks of using this mailing list through gmail... Just changing the subject back....
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>