Respond to comment

_posts/2024-06-12-simpler-encapsulation-with-immutability.html

@@ -347,4 +347,53 @@ <h2 id="comments-header">
 		</div>
 		<div class="comment-date">2024-06-18 08:47 UTC</div>
 	</div>
+
+    <div class="comment" id="7f2ed4d386144b378cae2206e8269a6d">
+        <div class="comment-author"><a href="/">Mark Seemann</a> <a href="#7f2ed4d386144b378cae2206e8269a6d">#</a></div>
+        <div class="comment-content">
+            <p>
+                Marken, thank you for writing. It's always interesting to learn new techniques, and, as I previously mentioned, the array-based implementation certainly seems to <a href="https://blog.janestreet.com/effective-ml-video/">make illegal states unrepresentable</a>. And then, as we'll see in the last (yet unpublished) article in this little series, if we also make the data structure immutable, we'll have a truly simple and easy-to-understand API to work with.
+            </p>
+            <p>
+                I've tried experimenting with the <a href="https://fsharp.org/">F#</a> script you linked, but I must admit that I'm having trouble understanding how to use it. You did write that it was a crude attempt, so I'm not complaining, but on the other hand, it doesn't work well as an example of good encapsulation. The following may seem as though I'm moving the goalpost, so apologies for that in advance.
+            </p>
+            <p>
+                Usually, when I consult development organizations about software architecture, the failure to maintain invariants is so fundamental that I usually have to start with that problem. That's the reason that this article series is so narrow-mindedly focused on contract, and seemingly not much else. We must not, though, lose sight of what ultimately motivates us to consider encapsulation beneficial. This is what I've tried to outline in <a href="/2021/06/14/new-book-code-that-fits-in-your-head">Code That Fits in Your Head</a>: That the human brain is ill-suited to keep all implementation details in mind at the same time. One way we may attempt to address this problem is to hide implementation details behind an API which, additionally, comes with some guarantees. Thus (and this is where you may, reasonably, accuse me of moving the goal post), not only should an object fulfil its contract, it should also be possible to interact with its API without understanding implementation details.
+            </p>
+            <p>
+                The API you propose seem to have problems, some of which may be rectifiable:
+            </p>
+            <ul>
+                <li>At a fundamental level, it's not really clear to me how to use the various functions in the script file.</li>
+                <li>The API doesn't keep track of <em>what</em> is being prioritized. This could probably be fixed.</li>
+                <li>It's not clear whether it's possible to transition from one arbitrary valid distribution to another arbitrary valid distribution.</li>
+            </ul>
+            <p>
+                I'll briefly expand on each.
+            </p>
+            <p>
+                As an example of the API being less that clear to me, I can't say that I understand what's going on here:
+            </p>
+            <p>
+                <pre>&gt; create 1 100 |&gt; set 1 50 |&gt; addItem |&gt; set 1 30;;
+val it: PriorityList = { budget = 100
+                         dividers = [0; 50; 100] }</pre>
+            </p>
+            <p>
+                As for what's being prioritized, you could probably mend that shortcoming by letting the array be an array of tuples.
+            </p>
+            <p>
+                The last part I'm not sure of, but you write:
+            </p>
+            <blockquote>
+                <p>
+                    "Crucially: since <code>set</code>, <code>addItem</code>, and <code>removeItem</code> must maintain the invariants, they must have "side effects" of altering other priorities."
+                </p>
+            </blockquote>
+            <p>
+                As <a href="/2024/06/24/a-mutable-priority-collection">the most recent article in this series demonstrates</a>, this isn't an overall limitation imposed by the invariant, but rather by your chosen API design. Specifically, assuming that you initially have a <em>23, 31, 46</em> distribution, how do you transition to a <em>19, 29, 43, 7, 2</em> distribution?
+            </p>
+        </div>
+        <div class="comment-date">2024-06-27 6:42 UTC</div>
+    </div>
 </div>