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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 |
Free forum by Nabble | Edit this page |