"Like" types
On Oct 26, 2007, at 5:11 PM, James Clark wrote:
Calling the second relationship "like" seems strange to me. An
object that stands in the strong relationship to a type is just as
like the type as an object that stands in the weak relationship.
The canonical term (both in theory and in real programming languages,
e.g. C#) for the strong relation is "is", not "like".
See the overview generator example for a pretty combination of the two:
function fringe(tree) { if (tree is like {left:, right:}) { for (let leaf in fringe(tree.left)) yield leaf for (let leaf in fringe(tree.right)) yield leaf } else yield tree }
Try it:
let tree = { left: { left: 37, right: 42 }, right: "foo" } for ( let x in fringe(tree) ) print(x)
It prints 37, 42, and "foo".
In Firefox 2, you can do exactly this example minus the is like test.
Instead some ad-hoc property-detection is required. See attached.
I found a couple of aspects of "like" types as presented in the overview a little bit unintuitive. First, let me check my understanding.
The language distinguishes two relationships between an object and a structural type:
there's a strong relationship, which the language currently models as "having" the type; with this relationship the object has the structure described by the type throughout its lifetime; conceptually, it is annotated with the type at birth
there's a weak relationship, which the language currently models as being "like" the type; with this relationship the object has the structure described by the type now, but may not have had it when it was created, and may not have it at a future point if the structure is mutated
Calling the second relationship "like" seems strange to me. An object that stands in the strong relationship to a type is just as like the type as an object that stands in the weak relationship. The degree of likeness is the same. What's different is the duration. Is the object just now like the type or is it guaranteed to be like the type now and for ever more? I would find "now" as the keyword more intuitive than "like".
I would also argue that the weak relationship is the one that is more obvious and natural and easy to understand (even though it doesn't translate into the same degree of implementation efficiency). For example, the overview starts by saying "A value v has type T if T describes v". It then contradicts itself in the very next sentence by saying that an object has a structural type if it was annotated with the type when it was created. The greater intuitiveness of the weak relationship seems even more obvious when you consider union types. Given this, wouldn't it better for the language to call the weak relationship "having" the type, and call the strong relationship something else ( e.g. "always" having the type, or being bound to the type)?
Finally, I wondering whether it's possible to dynamically set the readonly attributes of properties, so you could have something like the readonly operator in PostScript. If you have immutable structures, then the distinction between the strong and weak types disappears. Making an object readonly might be an attractive alternative to wrapping it. I also have a gut feeling that immutable data structures will play a part in a good solution to concurrency, which I'm hoping will be provided in ES5. So I guess this is an ES5 feature request.
James