[xplc-general] Re: dang!

[Pierre Phaneuf]

Now Joel is just being silly. If he wants to continue using tools
from the 1950s nobody's stopping him. Run-time compiling and linking
is a *strength* of .NET and Java and Perl and so on, and a reason
they're so popular. If that means you need a sophisticated runtime,
though.
It's simply a different compromise. Ranting about a weakness while
completely ignoring the advantages is a waste of time. I bet he could
have written a 4 MB statically-linked MFC countdown clock in much
less time than he took to write the article :).

There's a difference between "new Foo" right there in your code and
using a moniker that *possibly* could be "foo:" or using a category,
though. You *know* you won't be going anywhere without a Foo around if
you have a "new Foo", and not being able to say that is just silly.

Basically, .NET assemblies still have a symbol table, they just have
fancier names. But you can still look for the list of undefined symbols
for an assembly, and thus look for the assemblies providing them.

But statically linking? Come on, no one wants that!

[Pierre Phaneuf]

Your module loader will know exactly which dlls provide which UUIDs
(or monikers), and you could write a little script to grab just
those, throw them in a zip file, and ta da! Instant linker.

The loader knows where to find stuff when it's needed but it has no
idea what stuff *will* be needed, since that depends entirely on what
the program is doing at runtime. The only thing a script could do is
to be all-inclusive, which will result in a zip file much bigger than
18 KB (assuming there are modules equivalent to the whole .NET class
library).
Remember what happens when you statically link a WvStreams program
that uses WvMoniker? The linker has no idea that you're going to
request a IUniClientGen of the form "ssl:mai" and thus throws out the
entire content of libuniconf.so. Same problem.

Exactly, just like what i said in my first email on this subject.

BTW, that's one of the reasons I don't use totally automatic
registration of monikers and components, but rather have you call a
"registerStuff" function if you want to link against a library (be it
static or shared object). The really optional stuff, I put it into modules.

Since a .NET module contains a manifest of all the assemblies (dlls)
that it may need, .NET is actually in a better position to eventually
provide a static linker (though I doubt they will ever do that). Of
course, nothing prevents us from adding a IModuleDependencies
interface that could be provided by the moduleinfo object (or
shoe-horned somewhere in the ModuleInfo structure, if we also succumb
to 1950s technology :)), allowing the script to do a better job.

Ah, the 50's... :-)