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

Chris Muller asqueaker at gmail.com
Sat Sep 14 22:28:05 UTC 2013


On Fri, Sep 13, 2013 at 4:53 AM, Bert Freudenberg <bert at freudenbergs.de> wrote:
> I know it's side-stepping the discussion, but maybe this is helpful:
>
> Why do we need a per-package history provider?

It's not per package, it's per project, and only because Projects can
have restricted access.

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

Monticello is totally integrated into our ecosystem this is a feature
for Monticello.  I don't think this precludes getting history from a
different source, in fact, sometimes the best generalizations are
revealed by applying a pink-plane increment onto an existing reference
implementation.  If you have more concrete ideas about what you want,
I'm sure we could identify a possible generalization.

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

A long time ago, I used to have these same kinds of gut feelings --
that the best abstraction should be thought up a priori.  It was my
learning of XP principles combined with discovering Squeak's amazing
TSTTCPW solutions themselves that taught me ties should be as tight as
possible until they NEED to be looser.  And since the environment is
built for change, it works great.


> 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