"Like" types

[James Clark]

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