On Thu, Mar 31, 2011 at 7:23 PM, Ben Kloosterman <[email protected]> wrote:
> C# and .NET 1.0 had the same scheme but you were always checking if the type
> is correct , casting and sometimes boxing ( since object is a reference
> type) and generics gave quite a nice boost .
I guess I am confused by the reference to generics, because (from shap's email)
pure boxed List('a) is
elem: 'a
next:: List('a)
seems like a fairly generic list to me, I kind of assumed that any
inheritance mechanism would maintain the type variable mechanism.
> Also as I said interfaces are
> important here ( eg 1 or 2 members / fields tied to a type but multiple
> interfaces) and I would prefer them to Inheritance if a choice had to be
> made.
>
> Personally I think in 2000 you could get away with just inheritance but not
> any more . The real question is can you get away with them in v1 of Bitc
> and promise something better ?
I do think that interfaces/type classes more naturally represent some
problems such as undo/redo where you have an UndoStack, which can
contain different types, a naive implementation involves wrapping
these into an intermediate union, for adding to the stack. And a
custom vtable which does a switch on said union to dispatch the
operation.
this is the kind of thing I think interfaces/type classes would be
good for, since likely for each application you're going to have a
different list of types on the undo stack, causing relatively benign
code to differ from application to application. That said it does
seem do able just using union's and I could live with it (if i had
to).
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
