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" <ratm...@gmail.com> wrote: > On Sun, Jul 12, 2015 at 1:56 PM, Jonathan S. Shapiro <s...@eros-os.org> > 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 > bitc-dev@coyotos.org > http://www.coyotos.org/mailman/listinfo/bitc-dev >
_______________________________________________ bitc-dev mailing list bitc-dev@coyotos.org http://www.coyotos.org/mailman/listinfo/bitc-dev
