Right, the objective-c approach to the fragile base class problem is to have an symbol which stores the offset of the subclass relative to the base class, and when the base class that symbol gets patched up to reflect the base classes new size, this requires an addition of the end_of_base_class+fields_offset, to access a field... they deem this an acceptable overhead, not going to really argue with that its constant at least...
what I take umbrage with is that it puts you in a position where it is deemed acceptable to not know the actual shape of an object until runtime, and if you care or worse require that the size of an object at compile time *is* the size of an object at runtime, I find it an unacceptable position. On Sun, Jul 12, 2015 at 10:37 PM, Keean Schupke <[email protected]> wrote: > Really each Swift component is like a COM component and designed to be > dynamically loaded at runtime. > > On a unix/Linux platform its the equivalent of compiling every object as a > separate shared object library. What swift does, like C# does for COM is > hide the boilerplate of the dynamic library loading, making it automatic, > and hidden from the programmer. > > Objective-C is really two languages, a static 'C' fragment, and a Smalltalk > fragment (in the square brackets). Where the COM like functionality is > handled by the Smalltalk fragment. Swift integrates these two parts into a > single language. > > Keean. > > On 13 Jul 2015 2:24 am, "Matt Rice" <[email protected]> wrote: >> >> On Sun, Jul 12, 2015 at 1:56 PM, Jonathan S. Shapiro <[email protected]> >> wrote: >> > Matt: >> > >> > While size and offset unknowns may begin with a type variable, they are >> > compounded both by combinatorics and by overload resolution. The latter >> > especially in the presence of inlining. >> >> Precisely why the separate compilation strategy was limited to the set >> of types with known sizes and offsets, (or isolation between >> environments which can contain variables of :type, and actual type >> values... albeit pessimistically... there are some caveats where >> things really don't care and passing a shape as a parameter is >> adequate I don't have any answer for cases such as that yet >> really...), >> >> I don't really see this complication as adequate justification for >> post compilation relocation... though the separate compilation >> available is a bit weird compared to what we typically associate with >> the term I suppose... >> >> Anyhow, sorry for rambling off the topic of swift... >> _______________________________________________ >> bitc-dev mailing list >> [email protected] >> http://www.coyotos.org/mailman/listinfo/bitc-dev > > > _______________________________________________ > bitc-dev mailing list > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev > _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
