Jing Guo writes:
 > For example, if an E-type "is a" G-type, as _inheritance_, one would
 > have an E-type depending on the G-type at the compilation time.  As an
 > emulation, however, one may end up with the G-type (or its variation)
 > depending on all E-types for compilation.  Given my limited knowledge
 > about OO, this seems to be because many emulations use _composition_ to
 > emulate _inheritance_.
 > 
 > IMHO, this reverted relationship in a given emulation would be a quite
 > restrictive constraint on its usefulness for many potential system
 > applications.

Yukk.  I certainly agree that this would kill its usefulness on some
of my applications.  That's exactly one of the things I was looking
forward to OO to solve for me.  I have a library of types that may
occasionally be extended by a user of the library (well, my current
users wouldn't recognize in in those terms, but I recognize that this
is the essence of what is happening).  

As is now, with my f90 code, the user has to make a personal copy of
my library just to add a new extension.  Its easy in one sense (he
mostly just has to add another CASE to several SELECT CASE
constructs), but its quite inconvenient that he has to make a custom
copy of the library at all.  And if two users had independently made
extensions and later find that their code needs to work together,
then they need to merge their extensions because they both will
have made different modifications to the base library.  The
realization that OO could be used to help with this kind of mess
was one of the major things that attracted me to it.

-- 
Richard Maine
[log in to unmask]



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%