Re: Current work in compiler/language design.

hasan@emx.utexas.edu (David A. Hasan)
21 Nov 91 18:14:28 GMT

          From comp.compilers

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)
| List of all articles for this month |

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
--


Post a followup to this message

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