[squeak-dev] The Inbox: Monticello-cmm.568.mcz

Chris Muller asqueaker at gmail.com
Mon Sep 9 19:12:21 UTC 2013


You know, there is one little part of me that is with you -- It's when
I think about a Class definition having its category delimited by
dashes -- where does the Package name end and the Category begin?  I'm
torn between wanting to lock down a rule for that and leaving it
open-ended.

OTOH, by tying elements of Smalltalk (PackageInfo, Class and
MethodReference) to corresponding elements of the SCM tool (MCPackage,
MCClassDefinition, MCMethodDefinition), additional tools can be easily
built on the seam formed between these two.

So to answer your question -- by being able to ask the selected
Message its Package/MCPackage, I can also know its WorkingCopy, which
means I can know the Repositories it was loaded from.

If we have to support Classes and Methods being "defined in more than
one" Package, that means they have more than one WorkingCopy, which
means they're in more than one RepositoryGroup, which means means more
than one McModel.  So since the complexity explodes quickly, I just
want to have a good reason for it.

One suggestion would be simply to have both for now -- since 99% of
the time it's 1:1, #packageInfo could simply be implemented as  ^self
packageInfos ifNotEmpty: [ : infos | infos anyOne ].  The 99% case for
tools would work and whatever 1% cases would too..??



On Mon, Sep 9, 2013 at 1:07 PM, Bert Freudenberg <bert at freudenbergs.de> wrote:
> Well, what use case do you have for these proposed new methods?
>
> - Bert -
>
>
> On 2013-09-09, at 18:31, Chris Muller <asqueaker at gmail.com> wrote:
>
>> First, let me answer your question to say, "yes" we could do that.
>> But before we do, let's revive this same debate we had earlier this
>> year.  I'm starving for a compelling argument on this.  Back then I
>> had shown we don't have any meaningful examples in the image,
>>
>>     http://lists.squeakfoundation.org/pipermail/squeak-dev/2013-April/170234.html
>>
>> and, to this day, I guess we still don't..
>>
>> Back then, I had said:  "My goal w.r.t. this issue is to have a
>> simple, practical model useful for connecting Monticello elements with
>> their in-image counterparts.  What's yours?"  You mentioned Balloon3D
>> to belong to Balloon making it "easier for users".
>>
>> But using name-hierarchies is just _totally insufficient_ to represent
>> package-hierarchies.  As we make our packages more modular,
>> name-hierarchies become less effective.  e.g., what if Balloon3D
>> requires, say, "OpenGL?"  We are much better off defining package
>> hierarchies via something else like the nascent Installer extensions
>> ("package-definitions" category), or perhaps even Metacello.
>>
>> Back then, Dave's use-case example was a one-off where he simply
>> needed to rename his packages back to OSProcess.  The benefit in
>> Colin's case didn't make sense to me -- so I had asked for
>> clarification but I guess the discussion simply died out.
>>
>>     http://lists.squeakfoundation.org/pipermail/squeak-dev/2013-April/170261.html
>>
>> As I said, I'll surrender on this if I have to, but I really don't
>> like this idea of employing loosey-goosey String front-matching on
>> names of MC Versions and now Packages in order to form hierarchies for
>> the purpose of trying to coax the SCM tool into being something it
>> isn't.  I think it makes the code more complex while at the same
>> weakening its potential.
>>
>>
>> On Mon, Sep 9, 2013 at 7:26 AM, Bert Freudenberg <bert at freudenbergs.de> wrote:
>>> A class can be in multiple packages at the same time. These new #packageInfo methods only answer a random one.
>>>
>>> Wouldn't it be better if they returned a (possibly empty) collection of package infos, and the senders would deal with them?
>>>
>>> - Bert -
>>>
>>> On 2013-09-07, at 16:29, commits at source.squeak.org wrote:
>>>
>>>> A new version of Monticello was added to project The Inbox:
>>>> http://source.squeak.org/inbox/Monticello-cmm.568.mcz
>>>>
>>>> ==================== Summary ====================
>>>>
>>>> Name: Monticello-cmm.568
>>>> Author: cmm
>>>> Time: 7 September 2013, 11:23:41.529 am
>>>> UUID: 575ad6a3-2df6-4ae5-99a8-24c15f032558
>>>> Ancestors: Monticello-cmm.567
>>>>
>>>> - Adopt two more methods needed for browsing MC history.
>>>>
>>>> =============== Diff against Monticello-cmm.567 ===============
>>>>
>>>> Item was added:
>>>> + ----- Method: Class>>packageInfo (in category '*monticello') -----
>>>> + packageInfo
>>>> +     ^ PackageInfo allPackages
>>>> +             detect: [ : each | each includesClass: self ]
>>>> +             ifNone: [ nil ]!
>>>>
>>>> Item was changed:
>>>> ----- Method: MCHttpRepository>>httpGet:for: (in category 'private') -----
>>>> httpGet: actionString for: aMCDefinition
>>>> - self halt.
>>>>      ^ HTTPSocket
>>>>              httpGet: self locationWithTrailingSlash
>>>>              args:
>>>>                      { 'action'->{actionString}.
>>>>                      'mc-definition'-> {self serializeForRequest: aMCDefinition}}
>>>>              user: self user
>>>>              passwd: self password!
>>>>
>>>> Item was added:
>>>> + ----- Method: MethodReference>>packageInfo (in category '*monticello') -----
>>>> + packageInfo
>>>> +     "Answer the PackageInfo containing this method."
>>>> +     | methodCategory classCategory |
>>>> +     methodCategory := self category.
>>>> +     classCategory := methodCategory first = $* ifFalse: [ self actualClass theNonMetaClass category ].
>>>> +     ^ PackageInfo allPackages
>>>> +             detect:
>>>> +                     [ : each |
>>>> +                     "detect: [ : each | each methods includes: self ]" "<-- too slow"
>>>> +                     (each isYourClassExtension: methodCategory) or:
>>>> +                             [ classCategory notNil and: [ each systemCategories includes: classCategory ] ] ]
>>>> +             ifFound: [ : foundPackage | PackageInfo named: foundPackage packageName ]
>>>> +             ifNone: [ nil ]!
>>>>
>>>>
>>>
>>>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: a-defs-single-workingCopy.png
Type: image/png
Size: 20536 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20130909/7232b85d/a-defs-single-workingCopy.png


More information about the Squeak-dev mailing list