[squeak-dev] The Inbox: Monticello-ul.726.mcz

Chris Muller asqueaker at gmail.com
Tue Jun 30 23:12:00 UTC 2020


Hi Levente and Jakob,

> Am Mo., 29. Juni 2020 um 01:43 Uhr schrieb <commits at source.squeak.org>:
> >>
> >> + ----- Method: MCDirectoryRepository>>includesVersionNamed: (in
> category 'versions') -----
> >> + includesVersionNamed: aString
> >> +
> >> +       | comparable |
> >> +       comparable := ((aString endsWith: '.mcz') and: [ aString size >
> 4 ])
> >> +               ifTrue: [ aString allButLast: 4 ]
> >> +               ifFalse: [ aString ].
> >
> > Thank you for the suggestion. Why not use aString asMCVersionName
> > versionName here?
>
> Copy-paste from parent.
> When Chris introduced MCVersionName, he tried to use #asMCVersionName
> there, but later he reverted it according to the history of the parent
> method. It probably broke stuff (see below).


Hmm...  that's true, unfortunately, my comment only says, "Fix" it with no
other details.  I can't help but wonder if it was due to a #class test
somewhere..


>
> I think MCVersionName is something that should not exists in its current
> form. Why?
> - it's a subclass of ByteString, which limits the possible character set
>

It's common in the IT industry for Name identifiers to be restricted to a
subset of ASCII to support interoperation with as many types of systems as
possible.  It seems an appropriate choice for MC Version names.


> - #= is not commutative when one object is an MCVersionName, the other is
> a ByteString:
>         'foo' = 'foo.mcz' asMCVersionName. "==> false"
>         'foo.mcz' asMCVersionName = 'foo'. "==> true"
> - the above property breaks the contract of #hash and #=, so they
> sometimes misbehave in hashed collections
>

Not in actual practice, though.  The intent was that all uses of version
names would be ensuring they're dealing with the first-class
MCVersionName.  If one, theoretically, were to mix Strings and
MCVersionNames as in your example, yes, it would misbehave so... "don't do
that."  :)

 - Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200630/1abb3c90/attachment.html>


More information about the Squeak-dev mailing list