[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
|