Proposal: Static Typing

Randy Buchholz work at randybuchholz.com
Tue Mar 26 05:21:00 UTC 2019


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20190326/5ffabc9a/attachment.html>


More information about the es-discuss mailing list