3 Methods and Generic Functions

In Dylan, methods are not intrinsically associated with any particular class. (Methods can be thought of as existing outside of classes.) Like CLOS, Dylan is based on multi-methods, where the specific method to be called is chosen based upon the types of all its arguments.

The Dylan analog of a method is the method, but that simplifies the matter too much. In most OO languages the methods are defined as an integral part of the class itself, meaning that if you wish to use a method from another class it must be imported and called in a wrapper in your class.

In Dylan code is isolated from storage in functions. Many classes have methods that call their own functions, thereby looking and feeling like most other languages. However functions may also be generic functions, meaning they are not attached to a particular class, and can be called natively by anyone. Linking a particular generic function to a method in a class is accomplished this way:

define method turn-blue (w :: ) w.color := $blue; end method;

This definition is similar to those in other languages, and would likely be encapsulated within the class. Note the := setter call, which is syntactic sugarSyntactic sugar is a term coined by Peter J. Landin for additions to the syntax of a computer language that do not affect its expressiveness but make it "sweeter" for humans to use. Syntactic sugar gives the programmer (designer, in the case of specificat for color-setter($blue, w).

Generic methods come into their own when you consider more "generic" examples. For instance, one common function in most languages is the to-string, which returns some human-readable form for the object. For instance, a window might return its title and its position in parens, while a string would return itself. In Dylan these methods could all be collected into a single module called "to-string", thereby removing this code from the definition of the class itself.

4 Extensibility

This might strike some readers as very odd. The code to handle to-string for a window isn't defined in ? This might not make any sense until you consider how Dylan handles the call to to-string. In most languages when the program is compiled the to-string for is looked up and replaced with a pointer (more or less) to the method. In Dylan this occurs when the program is first run instead, the runtimeIn computer science, runtime describes the operation of a computer program, the duration of its execution, from beginning to termination (compare compile time). The term is also used as a short form when referring to a runtime library a program or library builds a table of method-name/parameters details and looks up methods dynamically via this table. That means that a function for a particular method can be located anywhere, not just in the compile-time unit. In the end the programmer is given considerable flexibility in terms of where to place their code, collecting it along class lines where appropriate, and functional lines where it's not.

The implication here is that a programmer can add functionality to existing classes by defining functions in a separate file. For instance, you might wish to add spell checking to all s, which in most languages would require access to the source code of the string class -- and such basic classes are rarely given out in source form. In Dylan (and other "extensible languages") the spell checking method could be added in the SpellCheck module, defining all of the classes on which it can be applied via the define method construct. In this case the actual functionality might be defined in a single generic function, which takes a string and returns the errors. When the SpellCheck module is compiled into your program, all strings (and other objects) will get the added functionality.

This still might not sound all that obvious, but in fact it is a common problem faced by almost all OO languages -- not everything fits into a class construct, many problems apply to all objects in the system and there's no natural way to handle this. For instance JavaThe Java platform consists of: The Java virtual machine The Java API In addition to Java itself, the following languages were specifically designed for the platform: Groovy Pizza GJ Java platform. is currently attempting to add this sort of system in AspectJAspectJ is an aspect-oriented extension to the Java programming language created at Xerox PARC. An AspectJ compiler weaves aspects into Java bytecode to implement crosscutting concerns. Aspects are written in a combination of Java and AspectJ and are wove, but this is proving very difficult and many Java programmers question the need for it in the first place. Suffice it to say, once you have used a language that allows extensions, you'll never want to go back.

A concrete example of this flexibility is what most other languages refer to as aspect oriented programming, where a particular function "cuts across" most of the objects in the system. This functionality cannot be provided in the basic language, leading to a series of add-ons and non-standard versions of the language as they invariably attempt to add it at some later date.

5 External links

Gwydion Dylan - host of two optimizing Dylan compilers targetting Unix/linux, Mac OS X, and Microsoft Windows

Functional Objects - developers of the Harlequin Dylan compiler for Microsoft Windows

Dylan Language Wiki

Dylan Language White Paper

http://directory.google.com/Top/Computers/Programming/Languages/Dylan/?tc=1

Harlequin (now Global Graphics) - former developers of commercial Dylan, Lisp, and ML compilers

More Dylan programming language links

Programming languages Failed Apple initiatives

<Hide>