[squeak-dev] History from network (was: The Inbox: Monticello-cmm.568.mcz)

Bert Freudenberg bert at freudenbergs.de
Fri Sep 13 09:53:58 UTC 2013


I know it's side-stepping the discussion, but maybe this is helpful:

Why do we need a per-package history provider? And why does it need to be tied into Monticello?

Wouldn't it be much nicer and more general to say: give me all versions of this class/selector combo, no matter from where?

There could be multiple "history providers". One would look at a local changes file. Another could query a URL. That one could use serialized MCDefinitions as a transport mechanism, but the history browser would be oblivious to that.

It is perhaps more of a gut feeling, but it seems to me that you're trying to tie things together very tightly that are better left loosely connected?

- Bert -


On 2013-09-09, at 21:12, Chris Muller <asqueaker at gmail.com> wrote:

> 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 ]!
>>>>> 
>>>>> 
>>>> 
>>>> 
>> 
>> 
> <a-defs-single-workingCopy.png>



More information about the Squeak-dev mailing list