Type parameters

Nicolas Cannasse ncannasse at motion-twin.com
Wed Sep 6 06:03:11 PDT 2006

>>There are a lot of useful cases. Basically when you don't have any
>>contraints on the type parameter, all you can do is manipulate it
>>abstractly. It works well for all kind of data structures and
>>containers, but fails to express reusable components.
> This is a sort of general comment. The point I'd like to address is a 
> sort of mental arithmetic, or weighting of features and comparison with 
> existing forms of safety and expressiveness. Add up these things in your 
> mind:
>    - Complexity of implementing the feature
>    - Complexity of proving the feature correct
>    - Complexity of explaining feature to users
>    - Complexity of resulting "clever" API-code that users will have
>      to understand in the wild (eg. note the difficulty many Java 5
>      users have with the parametric bounds all over its standard
>      library)

Fortunately, there is already big a good amount of papers written on
both implementation and correctness of bounded type-parameters. That
disables at least the first two points.

"Explaining" the feature to users is not mandatory. At first, users
don't need it. Then at the time they will need it, they should have
enough knowledge in the language to understand at least how it works.

Not having it mandatory of course means not to follow Java by having a
standard library making big usage of the feature. This is not because
they had this problem that the same will happen, of course.

What is important is the ability of users to express middly-complex
architectures easily, and without relying on dynamic typing. That's
exactly what the bounded type parameters are providing.

You can of course emulate them by passing a functional API as
constructor parameters, but that's more an ML functor-styled solution
than a OO one. Plus, unless you have proper functional types and at
least a bit of type inference, it's very difficult to have everything
being sound.

> My feeling is that bounded type parameters just aren't worth the cost. 
> That's why I avoided them in my proposal. Of course others might perform 
> the "mental arithmetic" above with different weights and come to a 
> different conclusion. But let's try to be concrete with examples.

The question is wether you allow users to write containers that know at
least a bit the API of the objects they are containing. One simple
example is a Hash, you might require its items to have method
getHashCode() : Int . Same for a sorted list which might require a
comparison function. I'm making quite generic examples but users can
easily comeup with their own problems.


More information about the Es4-discuss mailing list