diff options
Diffstat (limited to 'docs/doc/oop.html')
| -rw-r--r-- | docs/doc/oop.html | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/docs/doc/oop.html b/docs/doc/oop.html index 2e47476c..5915f033 100644 --- a/docs/doc/oop.html +++ b/docs/doc/oop.html @@ -118,7 +118,7 @@ </pre> <p>A stack is a particularly simple class to make because its state can be represented efficiently as a BQN value. Other data structures don't allow this, and will often require an extra <code><span class='Function'>Node</span></code> class in an implementation—see <code><span class='Function'>MakeQueue</span></code> below.</p> <h2 id="mutability"><a class="header" href="#mutability">Mutability</a></h2> -<p>An object is one way to transform <em>variable mutation</em> <code><span class='Gets'>↩</span></code> into <em>mutable data</em>. These are two different concepts: <code><span class='Gets'>↩</span></code> changes which value is attached to a <em>name</em> in a scope, while mutable data means that the behavior of a particular <em>value</em> can change. But if a value is linked to a scope (for an object, the scope that contains its fields), then variable mutation in that scope can change the value's behavior. In fact, in BQN this is the only way to create mutable data. Which doesn't mean it's rare: functions, modifiers, and namespaces are all potentially mutable. The difference between objects and the operations is just a matter of syntax. Mutability in operations can only be observed by calling them. For instance <code><span class='Function'>F</span> <span class='Number'>10</span></code> or <code><span class='Function'>-</span><span class='Modifier'>_m</span></code> could return a different result even if the variables involved don't change value. Mutability in an object can only be observed by accessing a member, meaning that <code><span class='Value'>obj.field</span></code> or <code><span class='Bracket'>⟨</span><span class='Value'>field</span><span class='Bracket'>⟩</span><span class='Gets'>←</span><span class='Value'>obj</span></code> can yield different values over the course of a program even if <code><span class='Value'>obj</span></code> is still the same object.</p> +<p>An object is one way to transform <em>variable mutation</em> <code><span class='Gets'>↩</span></code> into <a href="lexical.html#mutation"><em>mutable data</em></a>. These are two different concepts: <code><span class='Gets'>↩</span></code> changes which value is attached to a <em>name</em> in a scope, while mutable data means that the behavior of a particular <em>value</em> can change. But if a value is linked to a scope (for an object, the scope that contains its fields), then variable mutation in that scope can change the value's behavior. In fact, in BQN this is the only way to create mutable data. Which doesn't mean it's rare: functions, modifiers, and namespaces are all potentially mutable. The difference between objects and the operations is just a matter of syntax. Mutability in operations can only be observed by calling them. For instance <code><span class='Function'>F</span> <span class='Number'>10</span></code> or <code><span class='Function'>-</span><span class='Modifier'>_m</span></code> could return a different result even if the variables involved don't change value. Mutability in an object can only be observed by accessing a member, meaning that <code><span class='Value'>obj.field</span></code> or <code><span class='Bracket'>⟨</span><span class='Value'>field</span><span class='Bracket'>⟩</span><span class='Gets'>←</span><span class='Value'>obj</span></code> can yield different values over the course of a program even if <code><span class='Value'>obj</span></code> is still the same object.</p> <p>Let's look at how mutability plays out in an example class for a single-ended queue. This queue works by linking new nodes to the tail <code><span class='Value'>t</span></code> of the queue, and detaching nodes from the head <code><span class='Value'>h</span></code> when requested (a detached node will still point to <code><span class='Value'>h</span></code>, but nothing in the queue points to <em>it</em>, so it's unreachable and will eventually be garbage collected). Each node has some data <code><span class='Value'>v</span></code> and a single node reference <code><span class='Value'>n</span></code> directed tailwards; in a double-ended queue or more complicated structure it would have more references. You can find every mutable variable in the queue by searching for <code><span class='Gets'>↩</span></code>, which shows that <code><span class='Value'>t</span></code> and <code><span class='Value'>h</span></code> in the queue, and <code><span class='Value'>n</span></code> in a node, may be mutated. It's impossible for the other variables to change value once they're assigned.</p> <pre><span class='Function'>MakeQueue</span> <span class='Gets'>←</span> <span class='Brace'>{</span><span class='Value'>𝕤</span> <span class='Value'>t</span><span class='Gets'>←</span><span class='Value'>h</span><span class='Gets'>←</span><span class='Value'>e</span><span class='Gets'>←</span><span class='Brace'>{</span><span class='Function'>SetN</span><span class='Gets'>⇐</span><span class='Brace'>{</span><span class='Value'>h</span><span class='Gets'>↩</span><span class='Value'>𝕩</span><span class='Brace'>}}</span> |