[DGD] Java or LPC (DGD)?

[Felix A. Croes]

"Ben Chambers" <bjchamb at bellsouth.net> wrote:

> > DGD has persistence to a degree that is not possible with Java.
> DGD was written in C++, and provides that degree of persistence.  It is
> possible, therefore to get it in Java, but I agree that DGD has it built-in
> and easily accessible in a manner that would not be replicable in Java
> without some degree of work.

Using the same line of reasoning, I could argue that C/C++ also has
persistence, which of course is nonsense.

To reach the same degree of persistence that LPC has, you would have to
implement an interpreted language in Java.  Now <that> would definitely
be slower than LPC.

More about persistence below.


>[...]
> > - Java is multi-threaded
> Java is only multi-threaded if you code it right, so this is a minor issue,

Java is multi-threaded, period.  Do you mean that the problems associated
with this can be avoided?  If so, then you are right about that, but it
is definitely not a minor issue.


> especially since it is my understanding that DGD is headed in this direction
> anyways.

DGD is, LPC isn't.


>[...]
> > - Java has interfaces, LPC has include files
> Java has objects that you import, LPC has include files that act like
> inheritance.  C++ has the right idea, with include files and then
> inheritance being a distinct concept.

Surely you know that in LPC, inheritance and #including code are as
different as they are in C++?

Java's interfaces are actually an improvement on (the most common and
proper use of) include files.


> > - Java has much stronger typing (a bit too strong for a persistent
> >   system, perhaps)
> I'm not sure I understand.  I know what you mean by stronger typing, but how
> exactly would that be a problem in a persistent system?  Would it be a
> problem when you try to upgrade an object while the system is running?  It
> is true that this could be a problem in Java, but since DGD is written in
> C++ and has managed to solve this problem, it should be possible to solve
> it, although it may be more difficult.

It is a problem that can be solved -- by implementing an interpreted
language within Java.

A fully persistent mud must be able to upgrade code without being taken
down.  Java has some problems: it is hard/impossible (used to be impossible
but I'm told that there are now ways around it) to upgrade the code for
an object; and when you change a function prototype somewhere in a tangle
of related objects, this may result in linker clashes.

Then there is the problem of dependencies.  How do you upgrade a base
class from code that depends on that base class?  How do you deal with
threads running in dependent code at the same time?

I will take a look at the latest spec to see how/if Java has addressed
the upgrade problem and post on that later.


> > - Java has more basic datatypes (for example, different integer types)
> For a Mud this shouldn't be an issue, should it?

Within a mud, probably not.  For implementing a mud server, it might be.


> > - Java's error handling is more fine-grained; DGD has atomic error
> >   handling
> How exactly does DGD's error handling work?  I couldn't make a decision on
> which was better without a better understanding of what you mean by "DGD has
> atomic error handling"

There is a good explanation at

    http://dgd.is-here.com/faq/html/x440.html

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