Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!umich!yale!cs.yale.edu!briscoe-duke
From: briscoe-duke@CS.YALE.EDU (Duke Briscoe)
Newsgroups: comp.lang.misc
Subject: Re: Languages that allow extensions to classes
Message-ID: <22413@cs.yale.edu>
Date: 12 Apr 90 02:40:38 GMT
References: <16560@estelle.udel.EDU> <1238@fs1.ee.ubc.ca>
Sender: news@cs.yale.edu
Reply-To: briscoe-duke@CS.YALE.EDU (Duke Briscoe)
Organization: Yale University Computer Science Dept, New Haven CT  06520-2158
Lines: 24

In article <1238@fs1.ee.ubc.ca> mikeb@coho.ee.ubc.ca (Mike Bolotski) writes:
>Well, CLOS (Common Lisp Object System) for one.  And I really dislike 
>the above feature, actually.  In C++ the header file documents the entire
>behaviour of the class.  In CLOS that information is spread out all over
>the source files.   Not an example of proper software engineering, IMHO. 

Don't some CLOS systems have a browser which allows you to look at
(and edit) the source for a class' methods regardless of what file was
loaded to define the method?  I'm not a big fan of depending on plain
text files as a way of representing programs; richer data structures
(like what a browser uses) would be preferable, which are offered to
some extent by Smalltalk and some Lisp environments.

I think the other issue is whether a language has the capability of
incrementally extending or redefining definitions without having to do
massive recompilation.  This often involves an extra level of
indirection which has a performance price, but the performance price
can be "unpaid" by having a "final version" compiler which eliminates
the indirection, since that feature is mainly needed only during
development.  There are also security concerns if it is possible to
redefine the behavior of previously existent objects, but that can be
dealt with if necessary.

--Duke