jsdoc doesn't exist in production so it cannot provide any info to the runtime, making WASM interoperability and hot code optimizations impossible.
Let's please keep the discussion focused on the achievements current JS cannot possibly have, thanks. On Tue, Mar 26, 2019 at 9:06 AM Dan Peddle <d...@flarework.com> wrote: > It's really a shame few mention jsdoc anymore. It provides mechanisms to > achieve all of these developer experience quality of life improvements > without needing transpiling, and on top of standard js of various flavours, > progressively. > > > On 26. Mar 2019, at 06:43, Ranando King <king...@gmail.com> wrote: > > Doesn't V8 already use such a concept to manage optimization? When a > reference's structure mutates, V8 generates a new type by extending the > previous one with the changes, then kills any affected optimizations around > the mutated object, forcing re-optimization. Static types would essentially > provide a guarantee that such re-optimizations would be completely > unnecessary for the lifetime of the object since it would be impossible to > mutate the object's structure. It would also allow for early optimization > since the structure would already be known. These are the benefits of > static typing. It's not just a matter of developer trust but also engine > efficiency. > > On Tue, Mar 26, 2019 at 12:21 AM Randy Buchholz <w...@randybuchholz.com> > wrote: > >> I recently started doing a lot of ES, coming from C# and really missed >> “typings” at first. But once I learned to think more in es, they became >> less necessary – even cumbersome in some ways. The question for me on this >> really comes down to what is a ”type” and what value does it bring. As I >> see it, a type is a structural contract, in the same way an interface is a >> behavioral contract. The value of contracts is that they minimize the need >> to trust. I.e., if I pass a known-type to a function, I can know that it >> will have a specific structure (e.g., known properties and methods in a >> class). Without types, I must trust or check the structure. But, types >> aren’t really self-aware. It is the environment that enforces types. Once >> you have types, you must have what I call a “Type Authority”. Built-in >> types are always known by the authority, and when you declare a type, you >> are adding to what the authority knows. The authority can look at the code >> and do the “checking” of what is passed based on what it knows. Having >> types lets me not have to trust in what I am receiving – it can be verified >> for me. >> >> >> >> In a compiled language, types provide “hidden” value. The compiler can >> look at the entire code based and make optimization decisions around types >> (e.g., in-lining). In a dynamic, interpreted language, (for the most part) >> this doesn’t happen. Types must be processed at each point of use. So, the >> value of types stays mostly limited to knowing the structure. Which is >> though, extremely useful. The problem with static types, is that they exist >> at the wrong place in time. A static type is a design-time constraint. Yet >> the environment doesn’t really know about the type until each run-time use. >> This puts unnecessary limits on the language – adding a property at >> run-time (while scary at first) is one of my favorite features of the >> language. Static typing adds other layers of complexity – like namespaces. >> Locking down a type at design-time essentially “hijacks” a name. A static >> type “Person” must be consistent across the entire application environment. >> In uses like Web, where it is common to pull code from many remote sources >> and libraries, how does “Person” remain “static” across these? >> >> >> >> I would propose an alternative to static typing – the Type Authority. The >> Type Authority is a architecture component that (among other things) >> provides “scoped/run-time statics”. Essentially, the Type Authority is an >> application-wide dynamic repository of types, in the run-time environment. >> This opt-in feature would allow dynamically creating types, and then making >> them “fixed” them with application scope. Once registered, the type is >> basically static. Using a hierarchal approach and “dotted” naming notation, >> (e.g., library.component.typename) types can be localized or extended. For >> example, a library can be imported, and types given a “namespace prefix”. >> The qualified name would effectively be a static type within the >> application context. Properties could be dynamically added, and the new >> type registered as a ”child type” (e.g., Person => Person.Domain). This >> would then allow casting - (Person)DomainPersonInstance. A simple Type >> Authority would support basic “is a”/”typeof” capabilities. A more advanced >> system could provide factory methods. >> >> >> >> This approach provides a way to enforce the structural contract nature of >> types, while retaining the dynamic nature of the language. >> _______________________________________________ >> es-discuss mailing list >> es-discuss@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
