Well personally I prefer interface inheritance to implementation inheritance, and that can be combined with assemblies to manage shared-objects as well (it is an orthogonal problem).
Keean. On 13 July 2015 at 09:33, Matt Rice <[email protected]> wrote: > 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 >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
