Editing Dylan (programming language) (section)

==Classes==
Classes in Dylan describe <code>slots</code> (data members, fields, ivars, etc.) of objects in a fashion similar to most OO languages. All access to slots is via methods, as in [[Smalltalk]]. Default getter and setter methods are automatically generated based on the slot names.  In contrast with most other OO languages, other methods applicable to the class are often defined outside of the class, and thus class definitions in Dylan typically include the definition of the storage only. For instance:

<syntaxhighlight lang=dylan>
define class <window> (<view>)
  slot title :: <string> = "untitled", init-keyword: title:;
  slot position :: <point>, required-init-keyword: position:;
end class;
</syntaxhighlight>

In this example, the class "<code>&lt;window&gt;</code>" is defined. The &lt;class name&gt; syntax is convention only, to make the class names stand out—the angle brackets are merely part of the class name. In contrast, in some languages the convention is to capitalize the first letter of the class name or to prefix the name with a ''C'' or ''T'' (for example). <code>&lt;window&gt;</code> inherits from a single class, <code>&lt;view&gt;</code>, and contains two slots, <code>title</code> holding a string for the window title, and <code>position</code> holding an X-Y point for a corner of the window. In this example, the title has been given a default value, while the position has not. The optional ''init-keyword'' syntax allows the programmer to specify the initial value of the slot when instantiating an object of the class.

In languages such as C++ or Java, the class would also define its interface. In this case the definition above has no explicit instructions, so in both languages access to the slots and methods is considered <code>protected</code>, meaning they can be used only by subclasses. To allow unrelated code to use the window instances, they must be declared <code>public</code>.

In Dylan, these sorts of visibility rules are not considered part of the code, but of the module/interface system. This adds considerable flexibility. For instance, one interface used during early development could declare everything public, whereas one used in testing and deployment could limit this. With C++ or Java these changes would require changes to the source code, so people won't do it, whereas in Dylan this is a fully unrelated concept.

Although this example does not use it, Dylan also supports [[multiple inheritance]].