The Inbox: Monticello-cmm.568.mcz
Locked
The Inbox: Monticello-cmm.568.mcz
 
|
Re: The Inbox: Monticello-cmm.568.mcz
|
|
Re: The Inbox: Monticello-cmm.568.mcz
|
|
Re: The Inbox: Monticello-cmm.568.mcz
|
|
Re: The Inbox: Monticello-cmm.568.mcz
|
|
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 <[hidden email]> wrote: > Well, what use case do you have for these proposed new methods? > > - Bert - > > > On 2013-09-09, at 18:31, Chris Muller <[hidden email]> 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 <[hidden email]> 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, [hidden email] 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 (27K)
Re: The Inbox: Monticello-cmm.568.mcz
|
|
History from network (was: The Inbox: Monticello-cmm.568.mcz)
|
|
Re: History from network (was: The Inbox: Monticello-cmm.568.mcz)
|
|
| Free forum by Nabble | Edit this page |