<div dir="ltr">So, your definition of #packageInfo is to bring up the package where the class itself is defined, right?<div><br></div><div>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.</div>
<div><br></div><div>Is this secondary question of interest to you and the tools you're working on?</div><div><br></div><div>(* 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...)</div>
<div><br></div><div>-Chris</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Sep 9, 2013 at 12:12 PM, Chris Muller <span dir="ltr"><<a href="mailto:asqueaker@gmail.com" target="_blank">asqueaker@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">You know, there is one little part of me that is with you -- It's when<br>
I think about a Class definition having its category delimited by<br>
dashes -- where does the Package name end and the Category begin? I'm<br>
torn between wanting to lock down a rule for that and leaving it<br>
open-ended.<br>
<br>
OTOH, by tying elements of Smalltalk (PackageInfo, Class and<br>
MethodReference) to corresponding elements of the SCM tool (MCPackage,<br>
MCClassDefinition, MCMethodDefinition), additional tools can be easily<br>
built on the seam formed between these two.<br>
<br>
So to answer your question -- by being able to ask the selected<br>
Message its Package/MCPackage, I can also know its WorkingCopy, which<br>
means I can know the Repositories it was loaded from.<br>
<br>
If we have to support Classes and Methods being "defined in more than<br>
one" Package, that means they have more than one WorkingCopy, which<br>
means they're in more than one RepositoryGroup, which means means more<br>
than one McModel. So since the complexity explodes quickly, I just<br>
want to have a good reason for it.<br>
<br>
One suggestion would be simply to have both for now -- since 99% of<br>
the time it's 1:1, #packageInfo could simply be implemented as ^self<br>
packageInfos ifNotEmpty: [ : infos | infos anyOne ]. The 99% case for<br>
tools would work and whatever 1% cases would too..??<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On Mon, Sep 9, 2013 at 1:07 PM, Bert Freudenberg <<a href="mailto:bert@freudenbergs.de">bert@freudenbergs.de</a>> wrote:<br>
> Well, what use case do you have for these proposed new methods?<br>
><br>
> - Bert -<br>
><br>
><br>
> On 2013-09-09, at 18:31, Chris Muller <<a href="mailto:asqueaker@gmail.com">asqueaker@gmail.com</a>> wrote:<br>
><br>
>> First, let me answer your question to say, "yes" we could do that.<br>
>> But before we do, let's revive this same debate we had earlier this<br>
>> year. I'm starving for a compelling argument on this. Back then I<br>
>> had shown we don't have any meaningful examples in the image,<br>
>><br>
>> <a href="http://lists.squeakfoundation.org/pipermail/squeak-dev/2013-April/170234.html" target="_blank">http://lists.squeakfoundation.org/pipermail/squeak-dev/2013-April/170234.html</a><br>
>><br>
>> and, to this day, I guess we still don't..<br>
>><br>
>> Back then, I had said: "My goal w.r.t. this issue is to have a<br>
>> simple, practical model useful for connecting Monticello elements with<br>
>> their in-image counterparts. What's yours?" You mentioned Balloon3D<br>
>> to belong to Balloon making it "easier for users".<br>
>><br>
>> But using name-hierarchies is just _totally insufficient_ to represent<br>
>> package-hierarchies. As we make our packages more modular,<br>
>> name-hierarchies become less effective. e.g., what if Balloon3D<br>
>> requires, say, "OpenGL?" We are much better off defining package<br>
>> hierarchies via something else like the nascent Installer extensions<br>
>> ("package-definitions" category), or perhaps even Metacello.<br>
>><br>
>> Back then, Dave's use-case example was a one-off where he simply<br>
>> needed to rename his packages back to OSProcess. The benefit in<br>
>> Colin's case didn't make sense to me -- so I had asked for<br>
>> clarification but I guess the discussion simply died out.<br>
>><br>
>> <a href="http://lists.squeakfoundation.org/pipermail/squeak-dev/2013-April/170261.html" target="_blank">http://lists.squeakfoundation.org/pipermail/squeak-dev/2013-April/170261.html</a><br>
>><br>
>> As I said, I'll surrender on this if I have to, but I really don't<br>
>> like this idea of employing loosey-goosey String front-matching on<br>
>> names of MC Versions and now Packages in order to form hierarchies for<br>
>> the purpose of trying to coax the SCM tool into being something it<br>
>> isn't. I think it makes the code more complex while at the same<br>
>> weakening its potential.<br>
>><br>
>><br>
>> On Mon, Sep 9, 2013 at 7:26 AM, Bert Freudenberg <<a href="mailto:bert@freudenbergs.de">bert@freudenbergs.de</a>> wrote:<br>
>>> A class can be in multiple packages at the same time. These new #packageInfo methods only answer a random one.<br>
>>><br>
>>> Wouldn't it be better if they returned a (possibly empty) collection of package infos, and the senders would deal with them?<br>
>>><br>
>>> - Bert -<br>
>>><br>
>>> On 2013-09-07, at 16:29, <a href="mailto:commits@source.squeak.org">commits@source.squeak.org</a> wrote:<br>
>>><br>
>>>> A new version of Monticello was added to project The Inbox:<br>
>>>> <a href="http://source.squeak.org/inbox/Monticello-cmm.568.mcz" target="_blank">http://source.squeak.org/inbox/Monticello-cmm.568.mcz</a><br>
>>>><br>
>>>> ==================== Summary ====================<br>
>>>><br>
>>>> Name: Monticello-cmm.568<br>
>>>> Author: cmm<br>
>>>> Time: 7 September 2013, 11:23:41.529 am<br>
>>>> UUID: 575ad6a3-2df6-4ae5-99a8-24c15f032558<br>
>>>> Ancestors: Monticello-cmm.567<br>
>>>><br>
>>>> - Adopt two more methods needed for browsing MC history.<br>
>>>><br>
>>>> =============== Diff against Monticello-cmm.567 ===============<br>
>>>><br>
>>>> Item was added:<br>
>>>> + ----- Method: Class>>packageInfo (in category '*monticello') -----<br>
>>>> + packageInfo<br>
>>>> + ^ PackageInfo allPackages<br>
>>>> + detect: [ : each | each includesClass: self ]<br>
>>>> + ifNone: [ nil ]!<br>
>>>><br>
>>>> Item was changed:<br>
>>>> ----- Method: MCHttpRepository>>httpGet:for: (in category 'private') -----<br>
>>>> httpGet: actionString for: aMCDefinition<br>
>>>> - self halt.<br>
>>>> ^ HTTPSocket<br>
>>>> httpGet: self locationWithTrailingSlash<br>
>>>> args:<br>
>>>> { 'action'->{actionString}.<br>
>>>> 'mc-definition'-> {self serializeForRequest: aMCDefinition}}<br>
>>>> user: self user<br>
>>>> passwd: self password!<br>
>>>><br>
>>>> Item was added:<br>
>>>> + ----- Method: MethodReference>>packageInfo (in category '*monticello') -----<br>
>>>> + packageInfo<br>
>>>> + "Answer the PackageInfo containing this method."<br>
>>>> + | methodCategory classCategory |<br>
>>>> + methodCategory := self category.<br>
>>>> + classCategory := methodCategory first = $* ifFalse: [ self actualClass theNonMetaClass category ].<br>
>>>> + ^ PackageInfo allPackages<br>
>>>> + detect:<br>
>>>> + [ : each |<br>
>>>> + "detect: [ : each | each methods includes: self ]" "<-- too slow"<br>
>>>> + (each isYourClassExtension: methodCategory) or:<br>
>>>> + [ classCategory notNil and: [ each systemCategories includes: classCategory ] ] ]<br>
>>>> + ifFound: [ : foundPackage | PackageInfo named: foundPackage packageName ]<br>
>>>> + ifNone: [ nil ]!<br>
>>>><br>
>>>><br>
>>><br>
>>><br>
><br>
><br>
</div></div><br><br>
<br></blockquote></div><br></div>