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 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 ]! > > |
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 ]! >> >> > > |
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 ]! >>> >>> >> >> |
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) Download Attachment |
So, your definition of #packageInfo is to bring up the package where the class itself is defined, right? I would often think of the package more nebulously- where the class is defined and where any methods in the class are defined. Currently we only support one package where a class is defined (except for the odd string/pseudo packages you talk about below), unless I'm missed something.* We do, however, support lots of overrides/extension for the class in other packages, and I would assume that is fairly common. It is certainly encouraged by rants about how #isKindOf: or #class = MyClass being bad patterns - at which point I often fall back onto #isMyClass defined in Object, for instance.
Is this secondary question of interest to you and the tools you're working on? (* Of course, I'd love to be able to add variables to a class in a separate, non-base package for a class. Not a completely redefinition, but the ability to add them just for the contents of that extensions package. Maybe I'll fiddle around with the Traits definition next time I need this to figure out how to do it from that direction. Except I probably can't just add a trait to a class in an extension package, either, can I? bummer...)
-Chris On Mon, Sep 9, 2013 at 12:12 PM, Chris Muller <[hidden email]> wrote: You know, there is one little part of me that is with you -- It's when |
In reply to this post by Chris Muller-3
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 <[hidden email]> 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 <[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> |
On Fri, Sep 13, 2013 at 4:53 AM, Bert Freudenberg <[hidden email]> 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 <[hidden email]> 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 <[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> > > |
Free forum by Nabble | Edit this page |