Related articles |
---|
[8 earlier articles] |
Re: Current work in compiler/language design. chambers@cs.washington.edu (1991-11-18) |
Re: Current work in compiler/language design. sverker@sics.se (1991-11-19) |
Re: Current work in compiler/language design. ea08+@andrew.cmu.edu (Eric A. Anderson) (1991-11-19) |
Re: Current work in compiler/language design. objsys@netcom.com (1991-11-20) |
Re: Current work in compiler/language design. nick@dcs.edinburgh.ac.uk (Nick Rothwell) (1991-11-21) |
Re: Current work in compiler/language design. pardo@cs.washington.edu (1991-11-21) |
Re: Current work in compiler/language design. hasan@emx.utexas.edu (1991-11-21) |
Current work in compiler/language design. optima!cjeffery@cs.arizona.edu (1991-11-22) |
Re: Current work in compiler/language design. objsys@netcom.com (1991-11-25) |
Re: Current work in compiler/language design. preston@dawn.cs.rice.edu (1991-11-26) |
Re: Current work in compiler/language design. David.Chase@Eng.Sun.COM (1991-11-26) |
Newsgroups: | comp.compilers |
From: | hasan@emx.utexas.edu (David A. Hasan) |
Posted-Date: | 21 Nov 91 18:14:28 GMT |
Keywords: | design, OOP |
Organization: | UTexas Center for Space Research |
References: | 91-11-030 91-11-066 |
Date: | 21 Nov 91 18:14:28 GMT |
In an earlier post, in was mentioned that
>Standard 3rd generation programming (by CS reconning) falls apart when
>large or complex systems are involved, and incremental improvements
>for abstraction and reuse (etc.) to solve these problems often go by
>another name, yes, you guessed it, Object-Oriented! In fact if we add
>up all of the new facilities we would like to add to existing programming
>languages, this is also a common definition of object-oriented programming.
This seems to amount to the definition
OO := everything_that_is_good_in_the_world
and is a common feeling I get from discussions OO methods. The problem
here IMHO is that when "inheritance" and "dynamic binding" are glued
together under the OO heading, it becomes difficult for non-OO
practitioners to discuss either one in isolation. To *further* glue in
"resue", "abstraction" and (!) "all the new facitilties we ever would
like" into the definition of OO is an extreme disservice to OO. Object
oriented methods have a very appealing and intuitive foundation. But
these other issues are *not* unique to OO.
>And for a last word, I've worked with and seen quite a few compilers and
>am well aware of their strong and weak points, and the weakest,
>most bug-ridden, maintenance nightmarish point (Don't ever do this) is:
> They Were All Data Structure Oriented:
> Lack of encapsulation: unstructured, indescriminant, and undocumented
> access to primary data structures.
> Solution to 97% of all compiler related bugs and problems(by my best guess):
> Encapsulation as provided by object-oriented programs.
There are significant, powerful encapsulation mechanisms which can solve
these types of problems without resorting to OO methods. IMHO (very H,
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.
OO is conventionally defined too broadly. As I see it, there are many
useful concepts which have found their way into many OO languages and
techniques, but these concepts often have an existence and legitimacy
outside OO proper. Encapsulation is a perfect example.
--
| David A. Hasan
| hasan@emx.utexas.edu
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.