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, <[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: es-discuss Digest, Vol 131, Issue 29 (Ranando King) > 2. Re: Proposal: Optional Static Typing (Part 3) (Isiah Meadows) > > > ---------- Forwarded message ---------- > From: Ranando King <[email protected]> > To: es-discuss <[email protected]> > 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, <[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 >> >> > > > ---------- Forwarded message ---------- > From: Isiah Meadows <[email protected]> > To: kai zhu <[email protected]> > Cc: Brandon Andrews <[email protected]>, " > [email protected]" <[email protected]> > Bcc: > Date: Tue, 16 Jan 2018 15:32:36 -0500 > Subject: Re: Proposal: Optional Static Typing (Part 3) > Inline. > > ----- > > Isiah Meadows > [email protected] > > 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 <[email protected]> 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 <[email protected]> > 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 > > [email protected] > > > > 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 <[email protected]> > 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 < > [email protected]> 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 > >>> [email protected] > >>> https://mail.mozilla.org/listinfo/es-discuss > >> > >> > >> _______________________________________________ > >> 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 > > > > > > > _______________________________________________ > 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
