Dylan (programming Language) - Extensibility

Extensibility

This whole concept 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 of the 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; the runtime 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 spell-check 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 spell-check 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.