Re: .NET approach

>However, we
>cannot fully encapsulate them since we must depend on existing
(standalone)
>system objects to access/modify/control them.  We cannot make sure that
>someone else won't WRKOBJ on one of our component objects and screw things
up.

But, in fairness all around, you can't be sure that you won't have similar
problems in C++ or, potentially, even in Java.

You could certainly build up a nonpersistent user-based object scheme on
top of user spaces in C++ the day after tomorrow as long as you were
careful not to hand them out to those not your "friends."  (The key feature
is over-riding the "new" operator).

I certainly agree persistent, shared objects is a hard problem, especially
if you want an OS/400 level of security and enforcement.

An added aspect of this that is not immediately obvious is that OS/400
objects are large-grained (lots of data, lots of state) and C++ and Java
objects tend to be small grained (not always or typically a lot of data and
state in an individual object).  I'm guessing that user objects would have
requiements (size, scale) more often like C++ than like OS/400 data base
files.

If so, this makes the problem you pose difficult to solve.  So far, the
solution industry-wide has been not to have them directly; certainly not on
this level of granularity.  Has Gates and company solved this problem?


Larry W. Loen  -   Senior Java and iSeries Performance Analyst
                          Dept HP4, Rochester MN


+---
| This is the MI Programmers Mailing List!
| To submit a new message, send your mail to MI400@midrange.com.
| To subscribe to this list send email to MI400-SUB@midrange.com.
| To unsubscribe from this list send email to MI400-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: dr2@cssas400.com
+---