[DGD] Java or LPC (DGD)?

Felix A. Croes felix at dworkin.nl
Sun Aug 17 19:09:49 CEST 2003


"Albert Deinbeck" <albert-deinbeck at albert-deinbeck.de> wrote:

> After rereading the Java VW Spec I must sheepishly admit that you are
> perfectly right.
> This means of course that what you said about different classloaders and the
> namespace problem is also true.
> So each object has it's own namespace and communication has to take some
> external way in order to simulate a common
> namespace.
> In this regard there is a question I couldn't answer yet. Classloaders
> follow a delegation model the primordial CL being the root.
> If classes from custom CLs access the static member of a class loaded by the
> root CL, do they access the same or copies?

I believe it's the same one.  Classes loaded through separate classloaders
do share the same environment, they just don't live in the same namespace.


>[...]
> Apart from the fact that in the light of the above direct method calls
> aren't feasible...
> It seems the only way is to use reflection for method calls.
> I thought about using the Proxy class to connect to an actual class
> instance,
> but that brings the requirement of an interface for the class.
> I do not think interfaces should be set in stone, but they should change
> less frequently to
> allow for distinct names and files for them.
> Interfaces are mere logical constructs required by the compiler. The VM does
> not know them.
> So it's easy to replace an interface as long as you make sure all classes
> using it are recompiled.

As long as you don't let the wrapper class use the same interface as
the wrapped class, changing interfaces is quite possible.


> You could put all classes implementing the command interface in one package
> and compile them all
> once CommandInterface has changed, for instance...
>
> I would also think that java classes and world objects would not be equal,
> but that there is a bunch of java
> instances representing one world object. These would be serialized together
> and live in the same namespace...

Exactly.  In a manner of speaking, some classes would represent the "mud
server", and the others would be the "mudlib".  Only the latter would have
to be persistent.

As with DGD, you'd want the "mud server" part to be as small as possible,
and let everything else be handled by the "mudlib".

Regards,
Dworkin
_________________________________________________________________
List config page:  http://list.imaginary.com/mailman/listinfo/dgd



More information about the DGD mailing list