<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000;text-align: left" dir="ltr">
                                        Hi Chris -<div><br></div><div>Thanks for this explanation. I understand the trade-off between backwards-compatibility, performance, and modularity here. This background information would make a valuable class comment so that fellow Squeaker's can quickly grasp the status quo. :-) Especially for treating this case as "rarity" and not "example to be replicated".</div><div><br></div><div>Best,</div><div>Marcel</div><div class="mb_sig"></div>
                                        <blockquote class="history_container" type="cite" style="border-left-style: solid;border-width: 1px;margin-top: 20px;margin-left: 0px;padding-left: 10px;min-width: 500px">
                        <p style="color: #AAAAAA; margin-top: 10px;">Am 29.05.2021 01:49:05 schrieb Chris Muller <asqueaker@gmail.com>:</p><div style="font-family:Arial,Helvetica,sans-serif">Hi Marcel,<br><br>> ... MCVersionName?! A domain-specific subclass of String? Well, I consider this design rather unfortunate. In such a case, on might be better of to favor composition over inheritance. That's an anti-pattern. Please do not do that in your projects. :-) ... I suspect an optimization for a database ... not sure. Chris?<br><br>I introduced MCVersionName in 2011 as part of the work that unified<br>the MCRepository hierarchy.  At that time, external callers had become<br>completely dependent on the only-used subclass, MCFileBasedRepository.<br><br>So the MCVersionName design was partly for maintaining<br>forward-compatibility for older versions within the MC legacy, but<br>also because it's the soundest and simplest design.  The importance of<br>capturing explicit structure in "names" that have them (e.g.,<br>filenames, version names) is underrated.  MC should have harvested the<br>de facto structure into its code in the first place, but even then,<br>before the legacy, I don't think composition would've been the optimal<br>choice.  The requirement calls for a pure scalar value that can be<br>serialized to and from a human-readable filename, but with API access<br>to its structure which the MCTools needed to get off the ground (out<br>of the ditch).<br><br>There are a lot of names.  Composition would essentially require an<br>unnecessarily heavy "ValueHolder" that would either need to be<br>serialized or dynamically created all the time, disrupting the<br>effieciency needed out of the (pre-Spur) tools of that time.  Maybe<br>some would argue that a bunch of extension methods on String is<br>better, but I see domain-specific subclasses as merely a rarity, and<br>not an anti-pattern.<br><br>Best,<br>  Chris<br><br></div></blockquote></div>