Re: Current work in compiler/language design.

optima!cjeffery@cs.arizona.edu (Clinton Jeffery) writes:
// hasan@emx.utexas.edu (David A. Hasan):
// >OO is conventionally defined too broadly... ("OO") concepts often have an
// >existence and legitimacy outside OO... Encapsulation is a perfect example.
//
// I agree with almost everything David said, especially about OO being
// defined too broadly. But even in my narrowest definitions of OO,
// encapsulation is a key ingredient. OO people should not claim to have
// invented encapsulation, but I think encapsulation is a central idea of OO,
// and belongs in discussions of OO.


I think OO is defined differently than the usual, "What makes OO different
from what I'm using now(dynamic binding, inheritance)?" definition, which
I don't think is a good way to go about classifying programming languages
or methodologies. OO is a powerful methodology (and not just academic)
and entails more than just constructs. OO is best thought of as
simulating a problem domain (reality) as closely as possible and it is
this philosophy that distinguishes it from other methodologies.


I think you guys are caught in the "what feature syndrome", stating that
encapsulation (and etc.) are being tied to OO. They're not, they simply
comprise the means for OO right now (i.e. objects meet OO's goal). OO
features will continue to reflect better ways of simulation and will
continue to add new features as needed, the ones we have now may not be
the ones we have in the future, just look at prototypes. For now, I think
everyone is waiting to see how the dust settles and looking for ever new
ways to satisfy the goal of simulating reality. Maybe we should change
OO's name to something more applicable to its philosophy, an evolving
attempt to achieve realism in computer programming (as an infinitely
preferable means), rather than to its current constructs for supporting
it. And the constructs required by this admirable philosophy reach far
and wide.


And of course, (compilers/systems plug) as compiler writers and computer
architects we must keep up and provide the requisite technology. So, why
aren't more architectures being built to support OO better? (A lot of
programming is being done in OO and this is expected to increase, not
really for some of the rest). Why aren't the compiler texts being updated
to include the latest constructs? Why aren't the compiler writers always
talking about new ways to compile the latest in OO??? I might expect to
have to kick at the EE's for a while to build OO support into computers
since software people define their requirements, but anywhere in the
software community? Maybe if I get the chance to say this enough times
compilers and computer systems will begin to advance!-)


hasan@emx.utexas.edu (David A. Hasan) writes:
// here) one of the disappointing aspects of Eiffel is that it provides
// classes as the only possible encapsulation technique. I personally find
// Ada's packages a terrific tool to prevent the kind of "mucking" with
// details to which the previous post refers. Of course, current Ada has no
// inheritance-based OO capabilities. Modula-3 does, however, provides
// *both* classes and modules.


(C++ lacks packaging also). I think module/package structuring is
desirable too and there is nothing in OO precluding them. If they provide
a desirable, realistic means of structuring, and I'm sure they do, they
should be included as a natural part of OO. They add structure to the
file inclusion mess and the body/implementation part can add structure to
classes implementations. Packages and modules are often used to simulate
classes anyway, in such cases I think the class construct is simply more
appropriate.


Traditional Packages/Modules do have a major flaw though, as I recall.
They are hierarchical and simple indirect references between
packages/modules (which are very common) cause cycles and are not
hierarchical (this is a major design problem). This does not occur with
classes, but I've always attributed the hierarchical restriction to
general incompetence anyway and see no reason for it (not much work for an
arbitrary graph). I can vaguely recall posting to the Modula-2 newsgroup
years ago asking why this restriction was still in place (there was no
rational given), I hope they've removed it.


Booch, in various texts, has even advocated subsystems to structure
packages (although I've always thought separate clauses should apply to
packages) and groups of classes (to avoid a global naming problem, as I
recall). These are all presented as an integral part of the OO/ADT
paradigm.


Bob Hathaway
objsys@netcom.com
--

Return to the comp.compilers page.
Search the comp.compilers archives again.