Hello Chris
In the documentation thread you wrote that the PackageInfo mechanism is not used properly.
I assume because people do not know how to do it and that >t is not promoted enough
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@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.
Where it this information used then?
But do we REALLY want to bloat image memory with a bunch of "documentation" that no one will ever read and will be out of date within one release?
Nobody talks of bloat here.
A very reasonable goal is to have a 100 word description of what the package does or is/was supposed to do. This will include an URL.
Regards Hannes
On Fri, Aug 24, 2018 at 4:50 AM, H. Hirzel hannes.hirzel@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@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
squeak-dev@lists.squeakfoundation.org
-
Chris Muller -
H. Hirzel