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