<div dir="ltr">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.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 26, 2019 at 12:21 AM Randy Buchholz <<a href="mailto:work@randybuchholz.com">work@randybuchholz.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">





<div lang="EN-US">
<div class="gmail-m_-7591079287572917605WordSection1">
<p class="MsoNormal">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.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">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?<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">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.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">This approach provides a way to enforce the structural contract nature of types, while retaining the dynamic nature of the language.
<u></u><u></u></p>
</div>
</div>

_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
</blockquote></div>