Optional argument types

[Andreas Rossberg]

On 25 September 2012 17:50, John Lenz <concavelenz at gmail.com> wrote:
> The problem with structural types in a dynamic language is that the checks
> are potentially costly.  I'm not sure this is true for today's VMs or not
> (are the hidden classes they use sufficient to make these checks efficient?)
> but if nothing else runtime support for them will require additional bits.

Hidden classes are effectively nominal types, so they don't provide
much insight into implementing structural checks.

The problem with (dynamic) structural checks is that they have to go
deep. In the higher-order case (i.e. anything involving function
values or mutable state -- that is, any object) a lot of checking has
to be deferred to later uses of the value. Consequently, these cases
generally require dynamically wrapping checked values with respective
type information.

> Structural types are also intentional sloppy, related types can look the
> same.   For example, the structural question of "do you have an 'id' field"
> doesn't answer for the intended use of that field.

This is a frequent argument against structural typing, but IME, it is
pretty much irrelevant in practice (and certainly no more sloppy than
no typing).

Also note that private names would probably give you a way to enforce
nominal behaviour.

/Andreas