Editing Dylan (programming language) (section)

==Modules vs. namespace==
In many object-oriented languages, classes are the main means of encapsulation and modularity; each class defines a namespace and controls which definitions are externally visible. Further, classes in many languages define an indivisible unit that must be used as a whole. For example, using a <code>String</code> concatenation function requires importing and compiling against all of <code>String</code>.

Some languages, including Dylan, also include a separate, explicit namespace or module system that performs encapsulation in a more general way.

In Dylan, the concepts of compile-unit and import-unit are separated, and classes have nothing specifically to do with either. A ''library'' defines items that should be compiled and handled together, while a ''module'' defines a namespace. Classes can be placed together in modules, or cut across them, as the programmer wishes. Often the complete definition for a class does not exist in a single module, but is spread across several that are optionally collected together. Different programs can have different definitions of the same class, including only what they need.

For example, consider an add-on library for [[regex]] support on <code>String</code>. In some languages, for the functionality to be included in strings, the functionality must be added to the <code>String</code> namespace. As soon as this occurs, the <code>String</code> class becomes larger, and functions that don't need to use regex still must "pay" for it in increased library size. For this reason, these sorts of add-ons are typically placed in their own namespaces and objects. The downside to this approach is that the new functions are no longer a ''part of'' <code>String</code>; instead, it is isolated in its own set of functions that must be called separately. Instead of <code>myString.parseWith(myPattern)</code>, which would be the natural organization from an OO viewpoint,  something like <code>myPattern.parseString(myString)</code> is used, which effectively reverses the ordering.

Under Dylan, many interfaces can be defined for the same code, for instance the String concatenation method could be placed in both the String interface, and the "concat" interface which collects together all of the different concatenation functions from various classes. This is more commonly used in math libraries, where functions tend to be applicable to widely differing object types.

A more practical use of the interface construct is to build public and private versions of a module, something that other languages include as a ''bolt on'' feature that invariably causes problems and adds syntax. Under Dylan, every function call can be simply placed in the "Private" or "Development" interface, and collect up publicly accessible functions in <code>Public</code>. Under [[Java (programming language)|Java]] or [[C++]] the visibility of an object is defined in the code, meaning that to support a similar change, a programmer would be forced to rewrite the definitions fully, and could not have two versions at the same time.