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 <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 ]!
> >>>>
> >>>>
> >>>
> >>>
> >
> >
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20130909/757638ef/attachment.htm