Re: How should size of program grow with size of problem?

Julian V. Noble <jvn@fermi.clas.virginia.edu> writes:
>[OOP lets you reuse your code. That's the good part. The bad part is,
> you reuse your code. ;-)]


>From the observation that "optimizations for one case are often
pessimizations for another," it follows that a "basic problem" with OOP
and many other reuse models is that they imply a single underlying
implementation (yes, I know this isn't strictly true of OOP, but that's
how it generally gets used). In many cases you want an interface that
lets you tune or replace the underlying implementation to satisfy
performance constraints. Rather than argue this case online, I'll point
everybody off to


%A Gregor Kiczales
%T Towards a New Model of Abstraction in Software Engineering
%J Proceedings of the International Workshop on Reflection and
Meta-Level Architecture
%D November 1992
%C Tokyo, Japan
%E Akinori Yonezawa
%E Brian Cantwell Smith
%P 1-11


This also gives me an opportunity to grandstand my own opinions on the
matter, though you really should read Gregor's paper first:


%A David Keppel
%T Managing Abstraction-Induced Complexity
%R 93-06-02
%I University of Washington Department of Computer Science and Engineering
%D June 1993
%W anonymous ftp from `ftp.cs.washington.edu'


Sorry for the digression, but I just had to say it :-)


;-D on ( Subject-oriented deprogramming ) Pardo
--

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