RE: VisualAge for Java

["David Morris" <dmorris@xxxxxxxxxxxxx>]

Joe,

I can think of two good reasons to have multiple copies of the same class that 
have 
nothing to do with platforms.  The first is development/test environments.  
With VA/Java, 
you have to drop what you are doing and switch versions, ideally, you have two 
systems.
Another case is when you work with software that requires a specific version of 
something 
that changes frequently. It is not always possible to bring everything up to 
the same level 
all at once.

I think it would be nice if VA/Java allowed different version of the same 
package 
in different projects.  Ideally, VA/Java would recognize when I have multiple 
copies 
of the same package and ask me to select on export or when running.

We are currently using CVS, because we needed something that would not be real 
expensive 
and VA/Java users are in the minority here.  CVS is not a change management 
system, but 
it is easy to use and works with source pretty well. Change management is more 
than 
tracking source changes and if you want to automate that process you will end 
up paying 
quite a bit for it and it will likely work with a source change tracking system 
like VA/Java's, CVS, 
or Visual Source Safe.

David Morris

>>> joepluta@PlutaBrothers.com 05/13/01 12:11PM >>>
Concurrent access is a flawed concept in OO, IMO.  Separate development
trees is also flawed in an OO design; wrapper classes should be used
instead.  There is never a reason to have two versions of the same class,
with the exception of platform-specific implementations, which of course
should be VERY limited...

I can't think of a single reason I would ever WANT to have two designers
modifying the same class simultaneously, unless my projects were under
untenable time deadlines, or my class hierarchy was incorrect and I had
classes doing more than one basic function.  Under extreme circumstances
this may happen, but it should definitely not be a standard development
procedure.

As to split threads, I think it's a technique that requires VERY careful
scrutiny.  Other than for platform optimization, as mentioned above,
separate development threads are unnecessary in object-oriented programming,
unless you're talking about prototyping, and even then you should be using
encapsulation to separate the new code and the old code.  Direct
modification of a base class without having finished prototyping (and
thereby having collapsed the design tree) is, in my opinion, a direct path
to disaster.

Joe


Jim Mason wrote:
> There is a REAL model for management of classes.
> It DOES allow for concurrent access.
> It also allows, if needed, for split thread development where necessary.

+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: joe@zappie.net
+---