Hi Chris -

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".

Best,
Marcel
Am 29.05.2021 01:49:05 schrieb Chris Muller <asqueaker at gmail.com>:
Hi Marcel,

> ... 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?

I introduced MCVersionName in 2011 as part of the work that unified
the MCRepository hierarchy. At that time, external callers had become
completely dependent on the only-used subclass, MCFileBasedRepository.

So the MCVersionName design was partly for maintaining
forward-compatibility for older versions within the MC legacy, but
also because it's the soundest and simplest design. The importance of
capturing explicit structure in "names" that have them (e.g.,
filenames, version names) is underrated. MC should have harvested the
de facto structure into its code in the first place, but even then,
before the legacy, I don't think composition would've been the optimal
choice. The requirement calls for a pure scalar value that can be
serialized to and from a human-readable filename, but with API access
to its structure which the MCTools needed to get off the ground (out
of the ditch).

There are a lot of names. Composition would essentially require an
unnecessarily heavy "ValueHolder" that would either need to be
serialized or dynamically created all the time, disrupting the
effieciency needed out of the (pre-Spur) tools of that time. Maybe
some would argue that a bunch of extension methods on String is
better, but I see domain-specific subclasses as merely a rarity, and
not an anti-pattern.

Best,
Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210607/2f9a63f3/attachment.html>