On Fri, Aug 24, 2018 at 4:50 AM, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> Hello Chris

Hi Hannes (sorry for the delay in replying, finally catching up),

> ... (snip)
> The wiki has a description of PackageInfo
> http://wiki.squeak.org/squeak/3329
>
> It says what a package is (= a collection of classes plus methods in
> categories marked with *theNameOfthePackage).
>
>
> On 8/18/18, Chris Muller <asqueaker at gmail.com> wrote:
>> We've had PackageInfo for eons which I've subclassed in my own apps
>> forever to override several documentative as well as functional
>> methods in there.
>> But there was never any interest (in fact,
>> resistance!) in doing that in this community.
>
> Probably years back. Now it seems to be different :-)
>
>> Glad to see y'all finally
>> opening up to the idea, but I see no reason to have a "PackageInfo"
>> AND a "PackageModel".
>
> So we need an example in the wiki how a subclass of PackageInfo should
> look like and which methods it should contain.

Avi's original version of PackageInfo class>>#initialize still makes a
reference to the possibility of subclasses.  However, even though I
still have several stale subclasses of PackageInfo, I'm not sure we
should venture down this path afterall.  I used to think it seemed
like a good place for package-level #license, #copyright and #readMe
information.  At one point I think I even had #prerequisitePackages
which returned an Array of other package names which I thought I would
use for configuration, but never did.

After several years of meandering through that, I started thinking the
few things I was putting in my PackageInfo subclasses should simply be
combined into another pattern I was already compelled to use anyway --
one I refer to as the "World" pattern -- basically that every
application domain I create has a "root" object from which every
object in the application can be reached.  This object is already
responsible for #domainVersion, deployment and runtime scripts, so I
decided that other #license and #readme stuff fits just as well (if
not better), there.

Best,
  Chris