oops apologies, it's been some years since I was actively involved in objective-c, on the latter part I was mixing up method caching, (that is the classes can't change size at runtime, or after being added to the language runtime tables... which should have been obvious nonsense)
Anyhow, I still argue that the whole thing is fatally flawed from an accounting perspective... On Mon, Jul 13, 2015 at 12:26 AM, Keean Schupke <[email protected]> wrote: > That means you have to have the correct headers for the library version you > are linking against. You can do that be appending the library version to the > shared objects, and choosing to link against the one that matches the > headers used at compile time. > > I think neither Swiift, Objective-C nor C# do anything more sophisticated > than this. I would be interested if anyone knows otherwise. > > Keean. > On 13 July 2015 at 08:15, Matt Rice <[email protected]> wrote: >> >> only if the class heirarchy is from the same shared library as the >> field lookup... some language runtimes can cache the relocation e.g. >> when run in a loop if they have a way to invalidate the cache when an >> object size changes, others cannot... >> >> On Mon, Jul 13, 2015 at 12:03 AM, Keean Schupke <[email protected]> wrote: >> > Is the overhead not eliminated in the link phase when ld.so replaces all >> > the >> > relocation information with the absolute address loaded at? >> > >> > I would have thought after symbol relocation at link time (when the >> > shared >> > object is loaded) the machine code executed at runtime should/could be >> > the >> > same. >> > >> > Keean. >> > >> > On 13 Jul 2015 7:12 am, "Matt Rice" <[email protected]> wrote: >> >> >> >> 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 >> > >> > >> > _______________________________________________ >> > 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 > _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
