agesen@Neon.Stanford.EDU (Ole Agesen) (08/29/90)
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.
pallas@red-dwarf.Sun.COM (Joseph Pallas) (08/30/90)
In <1990Aug29.025227.19172@Neon.Stanford.EDU> agesen@Neon.Stanford.EDU (Ole Agesen) writes: >Take BETA, a compiled, statically >typed language, in which classes are NOT objects. In [PBETA] it is shown ... >classes need not be objects in order >to be constructed at runtime. We need only be able to manipulate descriptions >of classes at runtime! So what exactly is the difference between "classes are objects" and "descriptions of classes are objects"? Not much that I can see, except that in Smalltalk the form of the objects-that-describe-classes is dictated by the system. >All this, however, still leaves the original question unanswered: >"WHY SHOULD CLASSES BE OBJECTS?" I would also like to know! Why not? Object-oriented programming languages have the manipulation of objects as their foundation. So, if you want to manipulate classes, make them objects. joe P.S. Is there any easy way to get hold of a copy of this? >"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.
johnson@m.cs.uiuc.edu (08/31/90)
>I belong to the "modelling camp", i.e. I consider object-oriented programming >to be modelling. A program EXECUTION consists of a set of interacting objects >and it is a physical model of a part of the real world. The objects (and the >actions they perform) reflect real world phenomena (and the actions they >perform). The program execution is generated according to a prescription, the >program, which at the same time is a description of the real world part. I have an optimizing compiler and a operating system, both with an object-oriented implementation. It seems to me that you have to stretch things a little to say that either is modeling the real world. On the other hand, I've found that it is a big advantage to try to make the program as much like the theory as possible, i.e. the program is a representation (or a model) of the theory of compiling, virtual memory, etc. I think that I generally agree that programs should be models, but "real world" and "real world phenomena" is definitely too restricting. Computer scientists have a tendency to forget that the purpose of computers is to solve problems for their owners, but one should not go to the other extreme and forget that computers spend a lot of time performing activities like processor scheduling and type checking that are not very closely related to the owner's ultimate needs. >Real world phenomena are characterized by means of concepts, which have >classes as their model system counterpart. So objects reflect phenomena, >but classes reflect concepts. Phenomena have substance that change through >interactions. Objects model this by encapsulating state that change as a >result of methods being invoked. In contrast, concepts have no substance >and perform no actions, hence their model system counterparts, classes, >should not have state or define methods. Conclusion: classes are not objects >since they encapsulate no state, and do not perform action sequences. But we can model concepts, too. We can classify concepts, we can combine concepts, we can change concepts as our ideas improve, we can add new concepts and forget old ones. Some concepts imply other concepts, while some concepts contradict each other. It seems reasonable to me that concepts could have components, and that there could be relations between concepts. Thus, I don't think that the previous paragraph proves that classes should not be objects. Ralph Johnson - University of Illinois at Urbana-Champaign