On 10/04/2012, David Jeske <[email protected]> wrote: > In the absense of versioning issues, don't most dynamic language runtimes > handle modularity? Java/JVM, C#/CIL, Python, Ruby, Javascript... all can > have interfaces specified (whether checked by a compiler or not) and load > compatible classes at runtime. > > As far as I can see, both C-shlibs and CIL both (to some degree) at least > have some capability to handle multi-versioned dependencies because both of > them record the required dependency version in a way that is visible to the > runtime load/linker. Further, they can both load multiple versions of the > same shlib/DLL. Compare this with Java, Python, Javascript, etc.. which > don't have any record of such information to make available to the runtime, > nor can the runtime handle more than one version of a module/class loaded > because of name-clash.
I've always figured this problem is in the other direction. Java has classloaders (and eg. OSGi), in Python, classes are first-class, the problem is actually in the module system (although exocet showed that this could be fixed without the obvious hack if anyone cared), in Javascript, the syntactic mechanisms for module loading imply that types are first-class there, too (although extending existing types is a known problem there). The real problem is C; where the dynamic linker appears to provide one big ugly flat untyped namespace. You may be able to use and load two shared objects with versioned interfaces, but if they both provide functions from the earlier version, there's no telling which you will get. If they don't provide versioned symbols, you're just SOL. And forget about linking against the same library twice, say, to get two copies of all of the static state. You just don't do that in C; so I don't see how you can really call it an example of modularity. Mind you, I never figured BitC was attempting to fix the dynamic linker. -- William Leslie _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
