But as David Jeske specified earlier, c++ suffers from the fragile base class problem (In Objc++ as well) so confused about the relevance... and it has tagged pointers which suffices for some integer objects which will fit in the bits left over by object tag
On Mon, Jul 13, 2015 at 1:08 AM, Keean Schupke <[email protected]> wrote: > 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 > _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
