Type parameters

Nicolas Cannasse ncannasse at motion-twin.com
Fri Sep 8 03:53:10 PDT 2006

>    - The second implementation tries to correct this:
>      interface ISortable.<T> {
>         function lessThan(other: ISortable.<T>): bool;
>      }
>      now instances have to do something like:
>      class foo implements ISortable.<foo> {
>      }
>      But even this suffers from a problem that is in some sense the
>      dual of the problem you pointed out when complaining that the
>      dynamic behavior of the sort functions might change.

Yes, I agree with your point. But this is somehow an expected behavior
since overriding a method is intended to redefine a behavior.

> Indeed, part of the inherent rigidity of interface-based work is that 
> you have to know, a priori, which interfaces to inherit. Since you can't 
> know -- the required interfaces may not even be written yet -- you can 
> sometimes paint future library-users into a corner: if Alice wants to 
> use Bob's library with Carol's library, Bob's classes might need to have 
> been written in such a way as to implement Carol's interfaces. Alice 
> might need to subclass Bob's classes; and this is not always easy, if 
> Bob's public classes are themselves abstract or final.

Again, i'm not such a fan of interfaces, and in a functional world you
would tell the "right way" of doing things. I'm also convinced that the
functional approach is more flexible and powerful, my original thoughts
where based on the fact that I didn't know that ES4 will have structural
functional types, which would have make things harder. BTW updating the
wiki with more up-to-date material would be nice ;)

> As I said before, I don't claim to know for certain that there are *no* 
> high-value concrete examples that might make type parameter bounds 
> cost-effective. I'm just ... pretty sure sorted and/or hashed containers 
> aren't one of them. Can you propose any others?

Not easy one. I've been using the feature a few times in the haXe
standard library, but more often to express architecture constraints
than to provide an API. But the library is quite small and does not try
to be a "framework".


More information about the Es4-discuss mailing list