On Thu, Aug 29, 2013 at 10:14 AM, David Jeske <[email protected]> wrote:
> On Thu, Aug 29, 2013 at 9:54 AM, Jonathan S. Shapiro < [email protected] > >wrote: > >> > Yes. That's a big issue. Shifting the fixed-size arrays to the bottom is a >> useful special case, but it is defeated if further child classes are >> derived. >> > > Hmm.. yes, messy. Thus the reason fixed-size arrays are only allowed in > structs, which do not allow subtyping. > Nope. C# doesn't have a Nat kind, so the size of a fixed-size array cannot be parametric. There is no issue with subtyping a class that contains a fixed-size array in C#. Another limitation in C# is that a fixed size array can only contain non-reference types. That restriction is completely arbitrary and unnecessary. As with other restrictions, it reflects a limitation in the underlying CLR. > Somewhere in my core I'm convinced the solution to all of this is to end > implementation inheritence (and even implementation typing), and instead > rely on interface typing and implementation composition. We just need a > solution to that nasty traits/composition multiple-implementation issue. :) > I'm unclear how interfaces differ from inheritance, though. An interface is simply a degenerate class, so why does this move actually help anything? >From a type system perspective, it certainly doesn't simplify anything. Lack of inheritance would also present a bit of a problem for code migration. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
