I don't think there is a problem with abstracting the shared object operating system mechanics at the language level, but perhaps Objective-C++ is a better compromise, so you can have compile time C++ objects (after all having a dynamically linked Integer object seems problematic), and also dynamically-loadable Objective-C shared-objects.
This could be replicated by making modules dynamically loadable/linkable, or introducing an abstraction specifically for dynamic loading/linking (I quite like "assemblies" for this). Keean. On 13 July 2015 at 08:37, Matt Rice <[email protected]> wrote: > 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 >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
