"HarryO" <harryo / zipworld.com.au> wrote in message news:20010715.195319.1387036159.21835 / zipworld.com.au... > > Java (TM), but I don't want to have problem with Sun's lawyers if I > > forget > > the copyright :-)))) > > Fair enough. I have nothing they could weasle out of me :-). > > > H> you just not like writing that word? If the latter, what's a > > "parasitic" H> method? I've not seen that term used before. > > > > http://www.cs.uwm.edu/~boyland/papers/parasitic-methods.html I'd not heard that term before either. It is a rather weird although descriptive term for what is being done. The more "correct/popular" term in OO literature is "around" methods (from CLOS [lisp]); or its equivalent term "outer/inner" methods from (Simula, etc). The general concept is what is called a "wrapper" method. This is one of the popularly used techniques in aspect oriented programming facilities. In Smalltalk (and in particular my work in QKS Smalltalk and SmallScript) the general pattern is called a "wrapper" method. For specific aspect related support they are called "around" methods are part of the MOP services that also provide "before" and "after" methods which would be synonomous with the pre/post condition ideas as expressed in Eiffel's design by contract architecture. Noting that Ruby does not require static type declarations and is thereby a dynamically typed language, following Java designs is relatively pointless and will lead you down the wrong implementation path. You might want to check out the definitive work on this topic from the early 90's. The Common Lisp Object System book -- "The Art of the Metaobject Protocol" by Gregor Kiczales, et al. It is a straightforward read and will expose you to both the ideas and their pragmatic rationale. > > I obviously don't really understand what the different is between simple > overloaded methods and the concept of multimethods. There isn't any difference. This is just a terminology issue which depends on what "school" of thought the idea was generated from. The more general term "multimethod" predates the narrower term "overloading". The "overloading" term takes on quasi special meaning in the context of languages that have intrinsic "operators" but which were extended to give those operators user-definable "method" like behavior [witness C++]. In languages like Smalltalk and Lisp, what is commonly thought of as operators have always user definable methods and so the distinction was never necessary/meaningful. In my work on SmallScript/QKS-Smalltalk and its AOS Platform execution engine (as well as .NET) I've implemented hi-performance multi-method services. A Ruby implementation built on top of the underlying execution technology I developed for both the AOS Platform and the .NET platform would give Ruby free multi-methods. Unfortunately it could not follow the Ruby open-source model for things. Perhaps evolution in the Mono (Ximian) project to make a GNU.NET platform will make this possible. But, as of now, I'm the only party that has developed an efficient (dynamic dispatch) multi-method architecture for .NET and it is based on a lot of years of my personal work, R&D investment, and experience for which I intend to be compensated through licensing. There is a rich array of things that multi-methods enable and there are many type system related semantics that go along with such an architecture. The most obvious (frequently cited) example is the generalization of libraries for numerics and linear algebra. Where the classic technique (without multi-methods) is to use double dispatch. But there are many others such as foreign function interfaces, multi-threading safety, and a range of string and character processing services. Assuming the standard source base for Ruby is using Smalltalk (from which Self was derived) style dynamic dispatch then you have the basic foundations in the VM sources to extend it to support efficient multi-methods and adaptive jit compilation. -- -- Dave S. [ http://www.smallscript.net ] > I guess I'll do a > quick search to see if I can find some info. Unfortunately, not being a > member of the ACM, I couldn't download that paper. > > > H> This code confused me. > > > > modified version of ruby > > Ah!