On Tue, 2006-01-10 at 18:05 +0100, Nicolas Cannasse wrote:
> > Futhermore with dynamic loading you can load any
> > exported symbol from any library entirely dynamically.
>
> I have some problems with the C dynamic linker.
You are not alone .. :)
> > Hmm .. does Neko have private symbols? If you have
> > $export you need that (privates don't get exported,
> > its for helpers that are part of the implementation
> > but not part of the interface).
>
> What is the difference with globals ?
Well an example from Felix shows:
module X {
var x = 1;
private var y = 2;
x++; y++; // access private OK
X::y++; // Error, no visible y in X, public access!
}
open X;
x++;
y++; // lookup ERROR, can't find y, invisible
X::x++; // qualified lookup
Y::y++; // error
module Z {
var a = 1;
}
module Q { open Z; ++a; } // OK,
Q::a++; // error
open Q;
a++; // error
So .. private names aren't part of the public interface
of a module, they can only be accessed from inside
the module using unqualified names.
Oh .. just to be clear, modules aren't objects at
run time: they just provide a name lookup model.
All the variables in a module outside any function
are global variables. Variables declared outside
an explicit module like this:
var g = 1;
are actually in the 'main' module, which implicitly
wraps the input file .. so everything is in *some*
module. But at runtime the modules just disappear
and all those variables are globals. (Felix allows
local modules too .. ones inside functions .. since
all they do is provide a lookup namespace, there's no harm
in it).
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
--
Neko : One VM to run them all (http://nekovm.org)
