[pclasses-devel] rethinking the classloader/core deps

[stephan b. <st...@s1...>]

Responding to an IRC discussion Christian and i had, where we decided to 
put DLL loading into the System module and provide a basic Factory 
interface via the core API...

This just occurred to me:

In my CL's [CL==classloader] model there is no difference, API-wise, to 
loading a type from a DLL and loading a statically-linked type:

MyT * t = classload<MyT>( "MySubT" );

That MIGHT load MySubT.so, it might not. The client doesn't care if 
MySubT was generated over http and JIT-compiled on a cluster in 
Botswana. All the client wants is his object.

That flexibility is where the problem is: that means the CL interface 
MUST depend on the System module if it is to do any dynamic lookups, 
since System provides all file- and DLL-related stuff (rightfully so). 
That means i can't directly offer dynamic lookups through the same API 
transparency as the CL currently does.

After thinking about it for a while, and looking over the core API more, 
i'm gonna install the CL entirely in System. i will provide a basic 
Factory in the core (done, but not yet commited), but that means the 
default classloader won't do DLL loads by default. i will provide a 
functor-driven way to do that via the core API, though, by passing 
functors which know how to do dynamic lookups. i have a template-driven 
idea which should let clients replace the default (static) factory's 
internals to redirect it to the System one without the core knowing 
(similar to s11n's custom factory installation approach).

The PathFinder class i mentioned a few days ago now lives in System, but 
i haven't compiled it after sed'ing the functions to follow P 
conventions. Still working on the build port - the core lib compiles 
now, but i've gotta sleep before porting the others...

See ya!

-- 
----- st...@s1...   http://s11n.net
"...pleasure is a grace and is not obedient to the commands
of the will." -- Alan W. Watts