Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!decwrl!shelby!neon!agesen
From: agesen@Neon.Stanford.EDU (Ole Agesen)
Newsgroups: comp.object
Subject: Runtime Class Creation (was: the need for classes as objects)
Keywords: Dynamic class creation, dynamic linking, ROTTETANG.
Message-ID: <1990Aug29.025227.19172@Neon.Stanford.EDU>
Date: 29 Aug 90 02:52:27 GMT
References: <2259@esquire.UUCP> <9959@goofy.Apple.COM>
Organization: Computer Science Department, Stanford University
Lines: 72

In article <9959@goofy.Apple.COM> susser@apple.com (Joshua Susser) writes:
>When I was at Caltech in '84, Tzu-Mu Lin (one of Carver Mead's grad 
>students) created a VLSI analysis tool (I think it used predicted signal 
>delay times) in Smalltalk-80 as part of his thesis work.  As I recall, he 
>had a nice graphical tool for describing circuits.  Once the circuits were 
>specified, those descriptions were translated into Smalltalk code in the 
>form of classes and methods.  Since a VLSI circuit often has common 
>circuit elements duplicated many times, using classes as the 
>representation of behavior gave a lot of leverage.  Since Smalltalk-80 
>supports creating classes dynamically, the user never had to leave and 
>restart the system to include new changes.
...[Thinglab example and discussion left out]

I think Mr. Susser's example is a good illustration of why it is important
to be able to CREATE NEW CLASSES AT RUNTIME. So now it is time to quote
the original poster, Mr. Yost (yost@dpw.com), who, in article 
<2259@esquire.UUCP> writes:
>I've heard lispers and smalltalkers say that
>the ability of their languages to create
>classes at runtime is very powerful, even
>necessary, and that therefore statically-
>classed languages (shall we say) that don't
>allow this (e.g.  Eiffel, C++) are inferior.

I'm not sure what Mr. Yost means by "statically-classed" languages, but
my claim is that languages like Eiffel, C++ and BETA are not inherently 
weaker than Smalltalk in this respect. Take BETA, a compiled, statically 
typed language, in which classes are NOT objects. In [PBETA] it is shown 
how provision of a callable compiler combined with a dynamic loader and 
linker allow new classes to be constructed and integrated in a running 
program without disruption. The idea is: the program execution that 
should be extended (or somebody else) constructs DESCRIPTIONS OF the 
new extension classes. The descriptions can be represented as text objects, 
abstract syntax trees or whatever. Then the compiler is invoked to type 
check the extension classes and generate machine code, which the loader/
linker finally incorporates into the program execution that is to be 
extended. To make the point explicit: classes need not be objects in order
to be constructed at runtime. We need only be able to manipulate descriptions
of classes at runtime!
In another (unpublished) report, [DYNLINK], a prototype implementation in 
BETA of these ideas is presented. The scheme is very general: new extension 
classes can be subclasses of or aggregated from existing classes including 
previously constructed extension classes. There are no restrictions on 
"where" in the original program extension classes can be loaded; extension 
points do not have to be specified in advance. Full static type checking of 
both the original program and extensions are maintained. The code generated 
is not less efficient so programs not using the feature won't pay an 
efficiency penalty. Programs using the feature are slightly slower during 
start up due to dynamic linking, but once the code is loaded and linked, 
they perform at full speed.

All this, however, still leaves the original question unanswered:
"WHY SHOULD CLASSES BE OBJECTS?" I would also like to know!

Ole Agesen


References:
[PBETA]
"Persistent and Shared Objects In BETA"; O. Agesen, S. Froelund, M. H. Olsen;
Masters thesis, Daimi IR-89; April 1989, Computer Science Department, Aarhus
University, Denmark.   -- In the thesis concepts related to dynamic class
construction are discussed. It is shown how dynamic class construction can 
yield a sound basis for the design of persistent objects.

[DYNLINK]
"Dynamic Link and Load as a Basis for Implementing Extensibility"; O. Agesen,
S. Froelund; December 1989; Unpublished.   -- This report discusses 
implementation issues and measurements related to dynamic link and load of
compiled object oriented programs. Furthermore, it is demonstrated that 
extensibility is feasible to implement, resulting in a truly more flexible 
programming environment.