[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-kuml-devel
Subject:    Re: Design change
From:       Jake Fear <fear1 () home ! com>
Date:       2000-02-16 6:55:15
[Download RAW message or body]

Sorry everyone,
   I have been traveling for work, so I have not had a chance to properly follow my
mail and evaluate what is being discussed.  If this is really the best thing for
the project, then I'm for it. However, I'm not sure a full conversion is the best
idea.  I have not looked at the sources in question, so my opinion is biased.
However, if all this Java code already exists and has been tested, I don't see the
point of doing the full translation.  Even if we can automate it, the nature of the
Java language will mean that the C++ code will be nearly devoid of any memory
management code.  Translator utils can not take care of this kind of thing, so we
will have a monster on our hands to debug.  Also, every Java reference translation
will be either a pointer or reference or?.. in C++, depending on the translator.
So, there is another possible problem.  I would almost bet that these utils
translate to pointers, which means LOTS of leaky code.
I suggest that nobody put too much faith in Java->C++ translators.  My personal
suggestion is to build an interface in C++ that mirrors this API.  I'm sure a good
portion of our existing code would be relavent or,  another alternative (the one I
think is a better idea) is to ditch C++ as our implementation language, but I can
feel the heat from this suggestion already ;-).  However, if nobody here is worried
about speed to market/ease of implementation, the main advantages of Java are
pointless.  As I am still traveling and on very limited time I will not likely have
time to evaluate this source code anytime before this weekend.  Do note that the
/kuml/data/ code is fairly stable (at least I think so ;-) at this point, and was
written to be adaptable.  Before doing any massive rewrites, we should at least
evaluate the possibility of porting the existing code to an interface "borrowed"
from nsuml.  Remember, were talking about debugging over 118,000 lines of JAVA
code.  That could easily translate over 200,000 lines of C++ (Yes, Java is much
simpler).   We can't know just how much trouble this is until we get the generated
code in front of us.  Are there any utilities being looked at for this yet?

Cheers,
Jake

Darius Stachow wrote:

> Hi,
>
> Jake, as you would be extremly affected by the design change, what do you thing
> about it ?
>
>  --
> Open your mind ...
> Darius Stachow

[prev in list] [next in list] [prev in thread] [next in thread]