yost@esquire.UUCP (David A. Yost) (08/28/90)
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. Would some of you who have used this feature please give us some great examples of its use and perhaps show how horrible the workaround would have to be in a language that doesn't support it? I'm sure dynamic classes must make development environments better, but I'm particularly interested in examples not related to issues of the development environment. Thanks. --dave yost yost@dpw.com or uunet!esquire!yost Please ignore the From or Reply-To fields above, if different.
mephdbo@prism.gatech.EDU (Cosmic Stranger) (08/29/90)
It is good to have that facility if you are developing systems for engineering design applications..particularly systems aimed at supporting conceptual design. Very few do. My humble experience. :-) CS -- ------------------------------------------------ "I just stopped by your world on my long journey.. I have seen many a world under many a sun... But none so timeless as Your World under its Sun.."
susser@apple.com (Joshua Susser) (08/29/90)
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. Another better known example is Alan Borning's ThingLab, also written in Smalltalk-80. ThingLab is a constraint-based graphics environment. It looks a bit like a MacDraw-type editor, but you can connect the various shapes through constraints. A typical example would be constraining a point to be the midpoint of a line segment P stretch the line, and the point moves as well. The types of objects were represented as Smalltalk classes, with methods for the various constraints, all added dynamically and incrementally. In both of these cases, using classes really paid off. Both of these systems allowed sharing of behavior, and classes provided a perfect mechanism for that. If Smalltalk-80 hadn't had the ability to create and use classes at runtime, both these systems would have had to implement a similar, special-purpose mechanism for managing that sharing. In such a case, the code would end up much more obtuse, be harder to understand and maintain, and would probably run slower. Joshua Susser, Object Percussionist Apple Computer, Advanced Technology Group inet: susser@apple.com | link: susser.j | phone: 408/974-6997
dag@control.lth.se (Dag Bruck) (08/29/90)
In article <2259@esquire.UUCP> yost@esquire.UUCP (David A. Yost) writes: >I've heard lispers and smalltalkers say that >the ability of their languages to create >classes at runtime is very powerful > >... I'm sure dynamic classes must >make development environments better, but I'm >particularly interested in examples not >related to issues of the development >environment. I work on a research project aimed at developing a modelling and simulation environment for control systems. This is a development environment, but at least not restricted to software... Object-oriented concepts are used to describe models of control systems (class hierarchies, component hierarchies, etc). Because we use C++ as implementation language, we have had to implement an additional layer for representing the models. The reason is just that C++ does not allow creation of classes at run-time. I believe that limiting ourselves to a domain with some inherent structure (control systems) has made the mechanisms for maintaining and instantiating class hierarchies simpler, compared to the very general mechanisms needed in a general-purpose programming language. A discussion of why C++ classes cannot be used directly is found in: Bruck, Dag M (1988): "Modelling of Control Systems with C++ and PHIGS," Proc. USENIX C++ Conference, Denver, CO, USA. A follow-up paper (with some additional details, and new graphics) is: Bruck, dag M (1989): "Experiences of Object-Oriented Development in C++ and InterViews," Proc. TOOLS '89, Paris, France. The ideas and concepts for describing control systems with OO technology may in fact be the most interesting to you: Andersson, Mats (1989): "An Object-Oriented Modelling Environment," Proc. of the 1989 Simulation Multiconference, Rome. Italy. Andersson, Mats (1990): "Omola - An Object-Oriented Language for Model Representation," Technical Report TFRT-3208, Dept. of Automatic Control, Lund Institute of Technology, Box 118, S-221 00 Lund, Sweden. Any comments or feedback are of course gratefully accepted. Dag M. Bruck -- Department of Automatic Control Internet: dag@control.lth.se Lund Institute of Technology P. O. Box 118 Phone: +46 46-108779 S-221 00 Lund, SWEDEN Fax: +46 46-138118
MELTSNE@gecrdvm1.crd.ge.com (08/29/90)
My dissertation, a thermodynamics calculation system, depended heavily on the ability to define new classes and add new methods to old ones. I cannot imagine how I would have implemented such a system without these abilities. It simply would have to be a totally different program.
kitchel@iuvax.cs.indiana.edu (Sid Kitchel) (08/29/90)
yost@esquire.UUCP (David A. Yost) 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'd say that runtime creation of classes is absolutely imperative for database applications. By definition the OODBS will be running when the end user invents new classes. Another angle that I thought of when I saw the title of this posting is that it is a good idea to have a class as an object for messaging and for meta description. An OODBS will keep data dictionary like classes and the end user invented classes will definitely be objects in them. Their creation is also imperative at run-time. --Sid -- Sid Kitchel...............WARNING: allergic to smileys and hearts.... Computer Science Dept. kitchel@cs.indiana.edu Indiana University kitchel@iubacs.BITNET Bloomington, Indiana 47405-4101........................(812)855-9226
lgm@cbnewsc.att.com (lawrence.g.mayka) (08/30/90)
In article <2259@esquire.UUCP> yost@esquire.UUCP (David A. Yost) writes: >support it? I'm sure dynamic classes must >make development environments better, but I'm >particularly interested in examples not >related to issues of the development >environment. Consider a service embracing 1000 offered features, which can be requested individually or in any combination. The total number of service behaviors is therefore (EXPT 2 1000), or 2**1000 in Fortran. Each feature is fundamentally a protocol and hence neatly expressible as a class. Each service behavior is then neatly expressible as a subclass inheriting from the appropriate features. It may not be practical, however, to define a priori all (EXPT 2 1000) service classes. The alternative is to define each unique service class only when actually needed (i.e., requested by a customer) and not before. This requires dynamic class definition. Lawrence G. Mayka AT&T Bell Laboratories lgm@iexist.att.com Standard disclaimer.
oscar@cui.unige.ch (Oscar Nierstrasz) (08/30/90)
agesen@Neon.Stanford.EDU (Ole Agesen) writes: >I think Mr. Susser's example is a good illustration of why it is important >to be able to CREATE NEW CLASSES AT RUNTIME. <stuff deleted> >All this, however, still leaves the original question unanswered: >"WHY SHOULD CLASSES BE OBJECTS?" I would also like to know! I think the only way to properly answer this question is to first step back and consider the question: "Why should *anything* be an object?" Here are some of my favourite reasons: - to encapsulate behaviour (system modularity) - to encapsulate data (modelling concepts) - to factor out functionality (reusability) In each case, you make something an objects because you want to be able to do something with it: - ask it to perform a servuce - store, recall or modify information - combine it with other objects to create something new Now, what is a class? Basically it is a template for making objects: a "cookie cutter" that can be modified and extended to make a variety of different kinds of cookies (by choosing different initial values, binding class/type parameters, and by modifying or extending inherited behaviour). So, what are good reasons for wanting a class to be an object? 1. to view and manipulate the definition of the class (data encapsulation) 2. to model sharing of behaviour between classes (factoring functionality) 3. to extend or alter the definition in a controlled way (behavioural encapsulation) The first and the second are convenient for creating classes at run-time. Objects are just a convenient mechanism for encapsulating class descriptions. (Aside: is there a real need to distinguish between a class and the source text of the class, i.e., the class description?) It is not hard to come up with other ways of adding new classes, but they are not so appealing (e.g., sending a message containing the class description as a message to a "system" object which, as a side effect, creates the new class.) The third reason is more interesting. Suppose we wish to dynamically change the behaviour of an entire class of objects (i.e., the set of instances). This can be the case in information systems containg large numbers of persistent objects that encapsualate primarily information but also some behaviour (e.g., constraints on how the information may be accessed and modified). When changes occur in the requirements of the system, we would like to be able to change or extend classes without losing the instances. There has been a lot of work in the past few years on so-called "reflective" objects (objects that can change their own behaviour), most of it motivated by artificial intelligence (see recent OOPSLAs etc.). I have not seen so much work on applying this idea to evolving systems (outside of the work by Kim et al. at MCC on schema evolution in object-oriented databases), but this seems to me one of the most compelling reasons for wanting classes to be objects. Other opinions? Oscar Nierstrasz --------------------------------------------------------------------- Dr. O.M. Nierstrasz E-mail: oscar@cuisun.unige.ch Centre Universitaire d'Informatique Tel: 41 (22) 787.65.80 12 rue du Lac, CH-1207 Geneva Fax: 41 (22) 735.39.05 SWITZERLAND Home: 41 (22) 733.95.68 ---------------------------------------------------------------------
mario@cs.man.ac.uk (Mario Wolczko) (08/30/90)
Several posters have described applications in which the ability to create classes at runtime made the applications simpler, cleaner, etc. However, let me make a stronger, and perhaps more controversial claim. I would suggest that IF you agree that the future direction for object-oriented systems is to use persistent object stores as the principal mechanism for long-term data storage, THEN inevitably object-oriented systems will adopt not only classes as objects, but also run-time creation and *even mutation* of classes and hence object structure. My argument is based on the observation that it is impossible when designing a class to foresee all the uses that instances of that class may be put to, if those instances may exist for many years. An important property of a conventional database is the ability to restructure the database to cope with change. When we start developing object stores with millions, possibly billions, of objects, most of the value of these system will be in the objects, and not in the "programs". This is the case with large databases today: application programs come and go; the data is always there. In these systems it will be essential to change the behaviour and even the structure of objects as the system evolves, while preserving each object's identity. Only a handful of languages (such as Smalltalk) allow these sorts of changes at all. It seems to me that understanding how to manage this kind of evolution is essential if we are ever to get widespread acceptance of OODBs and persistent OOLs, but I don't see a lot of activity in this area. Mario Wolczko ______ Dept. of Computer Science Internet: mario@cs.man.ac.uk /~ ~\ The University USENET: mcsun!ukc!man.cs!mario ( __ ) Manchester M13 9PL JANET: mario@uk.ac.man.cs `-': :`-' U.K. Tel: +44-61-275 6146 (FAX: 6280) ____; ;_____________the mushroom project___________________________________
wwb@sps.com (Bud Bach) (08/31/90)
In article <55679@iuvax.cs.indiana.edu>, kitchel@iuvax.cs.indiana.edu (Sid Kitchel) writes: > I'd say that runtime creation of classes is absolutely > imperative for database applications. By definition the OODBS will be > running when the end user invents new classes. This depends on your DBMS Model. We have developed an extensible DBMS for an information processing system using Classic-Ada, an OOPL with static classes. Our approach was to have user definable class descriptions represented as objects and then construct the instances of user data from the class description object. Both the class description and the instances are implemented using persistent objects making the implementation rather straight forward. Of course the disadvantage is that there is an extra layer in the system. The point is that database applications may be developed with statically classed languages. -- Bud Bach Voice: 407 984-3370 Software Productivity Solutions, Inc. FAX: 407 728-3957 122 4th Avenue email: wwb@sps.com Indialantic, FL 32903 or: ...!uunet!sps!wwb
brucec@phoebus.phoebus.labs.tek.com (Bruce Cohen;;50-662;LP=A;) (09/01/90)
In article <3240@cui.unige.ch> oscar@cui.unige.ch (Oscar Nierstrasz) writes: > (Aside: is there a real need to distinguish between a class and the source > text of the class, i.e., the class description?) Yes. A class, considered as an object may contain state as well as code. In Smalltalk such state is embodied in classvars, in C++ in static data members. So there is a dynamic aspect to a class even absent changes in the "static" class description. --------------------------------------------------------------------------- NOTE: USE THIS ADDRESS TO REPLY, REPLY-TO IN HEADER MAY BE BROKEN! Bruce Cohen, Computer Research Lab email: brucec@tekcrl.labs.tek.com Tektronix Laboratories, Tektronix, Inc. phone: (503)627-5241 M/S 50-662, P.O. Box 500, Beaverton, OR 97077 -- --------------------------------------------------------------------------- NOTE: USE THIS ADDRESS TO REPLY, REPLY-TO IN HEADER MAY BE BROKEN! Bruce Cohen, Computer Research Lab email: brucec@tekcrl.labs.tek.com Tektronix Laboratories, Tektronix, Inc. phone: (503)627-5241 M/S 50-662, P.O. Box 500, Beaverton, OR 97077
cox@stpstn.UUCP (Brad Cox) (09/01/90)
In article <55679@iuvax.cs.indiana.edu> kitchel@iuvax.cs.indiana.edu (Sid Kitchel) writes: >yost@esquire.UUCP (David A. Yost) 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. > Classes as objects, like dynamic binding, are entirely unnecessary if your application domain can be approximated as a closed universe in which everything is known when the universe is created by the compiler and linker. Examples of closed universes are most conventional programs, especially those that are built by a single programmer Class as objects, like dynamic binding, become essential when your application domain cannot be approximated as a closed universe, but must be responsive to things entering or leaving after the application has been constructed by the linker, or even while it is running. Examples of open software universes are systems where objects are persistent, distributed, and/or shared, where many programmers are involved, or when components are to be aggressively reused across diverse (poorly-coordinating) organizations. Examples: an automobile engine is a closed universe. The passenger compartment and trunk are open universes. -- Brad Cox; cox@stepstone.com; CI$ 71230,647; 203 426 1875 The Stepstone Corporation; 75 Glen Road; Sandy Hook CT 06482
egdorf@zaphod.lanl.gov (Skip Egdorf) (09/01/90)
In article <2259@esquire.UUCP> yost@esquire.UUCP (David A. Yost) writes: > I've heard lispers and smalltalkers say that > the ability of their languages to create > classes at runtime is very powerful, ... > > Would some of you who have used this feature > please give us some great examples of its use > and perhaps show how horrible the workaround > would have to be in a language that doesn't > support it? ... I can give one example from my current domain of discrete event simulation. In a simulation that includes modelling of decision processes, those decision process may decide to instantiate new classes of objects. The domain of possible classes of objects that could be decided upon can be very large; so large in fact that all could not be configured in any current implementation. A weak analogy would be be a compiler that works by explicitly (rather than implicitly) representing all possible strings of a language. The particular example in mind is a simulation of an air combat system where a particular situation results in the configuration of a squadron of aircraft composed of a particular airframe, a particular set of sensors, a particular set of weapons, a particular type of crew, etc. A runtime creation of a class of these aircraft, with a squadron built from instances created from this class, is a rather nice implementation. The number of possible classes, when all the various "mixins" are considered can be quite large. > ... I'm sure dynamic classes must > make development environments better, but I'm > particularly interested in examples not > related to issues of the development > environment. > > --dave yost > yost@dpw.com or uunet!esquire!yost The line between development environment and delivery system can be thin as well. Consider an analyst using the simulation system above to answer some question about use of air power. The analyst will produce a scenario describing an initial state of the model that will contain a squadron of these aircraft here and another squadron over there... Is the initialization of the model, with dynamic class creation from the scenario scripts, a development environment? The Analyst, considering the simulation model as an environment for exploring the use of air power, might answer "Yes" while the programmer, considering the simulation model an end product, would answer "No." Skip Egdorf hwe@lanl.gov