On Thu, Aug 29, 2013 at 9:54 AM, Jonathan S. Shapiro < [email protected] >wrote:
> On Thu, Aug 29, 2013 at 9:49 AM, David Jeske <[email protected]> wrote: > >> (2) The naive approach is going to parametrically instantiate for each >> SIZE of a string, not each type of string, because the size affects the >> offset of some_other_field. I think this may be why they punted safe >> fixed-size-strings. In order to share parametric instantiations, we'd need >> some kind of fancy offset indirection for a single instantiation. Perhaps >> shifting all fixed-size arrays to the bottom, and then added >> offset-and-length information as static class fields. >> > > 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. 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. :)
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
