/// missing section where I was going to do a multiple inheritance version, but ran out of time. /// C++ can handle multiple inheritance too. This is not a constraint that C++ imposes. Like C, LISP did not originally have the OO constructs, but what is impressive is that with LISP, the basic LISP language did not need to be moddified to add the OOP extentions, named CLOS, to the language. The OO extentions were able to be written in LISP, and could be loaded at run-time, yet the extentions are still able to operate on first order objects. In fact not only is this how it *can* be done, it's the way it's acutally done ever every LISP implementation that I know of. And doing this allows us to switch implemetations of the OO lisprary to ones that better suit our needs. This does not demonstrate a constraint imposed by C++, but demonstrates that C imposes constraints that did not make it practical for the OO extentions that make up C++ to be written as a replaceable library. In LISP this is not only able to be replaced, but is regularly replaced by other implementations either for efficency of momory, speed, or for variations of syntax and semanitcs. I saw one guy who had written a OOP library that did what he called "prototype based inheritance", which while i don't fully understand the details of it, seems to be a differnt way of inheriting properties from other objects. Now having so many versions of the OOP libraries gives us great flexability in what sub-languages we can design to implemnt our programs, but it also presents us with a problem. If someone has written a neat library using a OOP which we will call LOOPS, and someone else writes another neat & usefull libarary using the OOP called CLOS, we find out that objects from the two libraries won't interace with each other right, when we try to use bolth libraries in our program. This is because the don't use the same protocall. After a long period of time, and after much research & debate a facinating solution was found, which I consider to be one of the current triumphs of the computing world. The solution was named MOP, the Meta Object Protocal. MOP is a implementation of the CLOS sub-langauge written in the CLOS sub-language. This might sound strange, to implement something in itself, so let's take a look at this phenomina, and how it can help ease constraints: ----- Reflection: Reflection in it's generalized term, when someone or something, reasons about himself/itself. So when you think about why your going to go get drunk at that party next week, your "reflecting". In the scope of computers, it's usually used in reference to lanugages being given access to thier own implementation details. Lets look at some examples. Linux is self-hosting. This means that linux is developed, and compiled under linux. GCC is written in C (check this out more) linux modules can be written compiled and loaded during run-time imagine the kernel being borken up into lots of pieces, each piece being loadable module talk about micro-kernel talk about null-kernel with a null-kernel one could rewrite the entire "kernel" while it's operating. one could make the "kernel" operating differntly for differnt processes. talk about how reflection can remove constraints. ////// Now the MOP, being CLOS implemented in CLOS, means that there is a class called class, which is used to create a object of this type that represents the class whenever someone calls defclass. This object keep track of the methods that are available to objects of this class, and where to find the correct methods in the inheritance tree. Now after a "defclass x" is called there is a object of type class, that represents the class named x, and it's located somewhere on the "inside" of the MOP implementation somewhere. This gives us a unique opportunity. When developers are writing OO programs, they need to know which methods are available to which objects. Usually they didn't write the classes for these objects, and have little knowledge about them. Therefore "class browsers", software that helps you pick out a class, and htells you about all it's avaiable methods, is great for this purpose. If we were to add to the CLOS protocal a way to pass the class objects to the user, then the user would be able to write a class browser in CLOS/LISP with the current routines that are supporting the rest of his program, and without having to learn a lot of new constructs to do it. As you might guess, this has been done when defining the MOP protocall, and class browsers can be written very easily inside of LISP/CLOS/MOP using these extentions. (note: java does this too, which is why you see so many java class browsers in the java industry) *discussion marker* ----------- Now internal to the CLOS implemtation the class objects ******(is it the class objects, or the object class?) that weve been discussing have a clup of code, which when a method is called on the object, it sorts through the entire tree of classes, and find the correct method to call. This clump of code that handles method calls, is implemented as a method. Thies means that we can override it by makeing a new class, from which we inherit everything from the class called object. We then override the method with a new method with the same name, but searches the inheritance tree using the LOOPS algorythm. When we do this, any object made from our new class will use the LOOPS inheritance technique. Any object made from the defalut class will use the CLOS inheritance technique. Thus we can create the LOOPS object, and use that as the basis to load our usefull library that we wanted to use eirlier, but that needs LOOPS inheritance, while still using our usefull libraries that depend on CLOS. This solved the problem we encountered, and does so in a elegant way, allowing us great flexibility in the first order languages we can design to solve our problems with. *discussion marker* this last section has been how to use unconstrained languages, wihtout imposing constraints on yourself. The ideal language would be completely written in itself, and would be capable of being completely re-written from the language provided to the user, at runtime. Other changes to the system can be made, to count how often a method is called, and to write caching-routines to speed up those methods that are called often. <<>>