Hi Chris,

> On Aug 18, 2018, at 10:12 AM, 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.  Glad to see y'all finally
> opening up to the idea, but I see no reason to have a "PackageInfo"
> AND a "PackageModel".

Doh!  Of course.  Forgive me.  So per-package subclasses of PackageInfo or extent PackageInfo and store instances?  I expect using the class will be less problematic.

> 
> 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?  We can't keep our existing documentation (wiki,
> etc.) updated, I'd suggest seeing if we can actually commit to
> cleaning that up before harming the image with new kinds of
> documentation.

The thing is about a per package class is that it’s not separate and is easy to keep up to date.  If there’s good tool support (eg a help browser like system for organizing documentation & examples) then there’s incentive to keep it up to date.

And these things should be trivial too strip for deployment if one wants.

> 
>> On Sat, Aug 18, 2018 at 9:07 AM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>> 
>> 
>> On Aug 18, 2018, at 6:02 AM, karl ramberg <karlramberg at gmail.com> wrote:
>> 
>> WebClient and WebServer are the only packages that have real HelpBrowser
>> documentation for both reference and use.
>> It would be nice to have similar documentation for other classes. But the
>> framework is pretty much there
>> 
>> 
>> +1000.  But this should be *in each package*.  Pharo just introduced a
>> PackageModel or some such off which one can hang various package attributes.
>> Each package can have a subclass of this named <PackageName>PackageModel (eg
>> KernelPackageModel).  The most basic thing is something that describes what
>> the package does.  Wonderful things like Nebraska remain underused because
>> it is not described briefly and hence is unknown to most users.  Maybe this
>> can be a focus for the next release.  Let’s get 5.2 out ASAP and then aim
>> for 6.0 to be an approachable release.
>> 
>> 
>> Best,
>> Karl
>> 
>> 
>>> On Sat, Aug 18, 2018 at 12:58 AM David T. Lewis <lewis at mail.msen.com> wrote:
>>> 
>>>> On Fri, Aug 17, 2018 at 05:42:24PM -0500, Ken Causey wrote:
>>>>> On 8/17/2018 4:40 PM, tim Rowledge wrote:
>>>>> 
>>>>>> On 17-08-2018, at 1:19 PM, Keith <keithy at consultant.com> wrote:
>>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> where do we put documentation these days?
>>>> 
>>>> While we are on this subject has anyone looked into adding documentation
>>>> at the category and/or package level? As someone who is barely paying
>>>> attention anymore but occasionally gets an itch to do some work in
>>>> Squeak it is really difficult to figure out what is already on hand in
>>>> an image at a high level, higher than per-class.
>>>> 
>>> 
>>> I do not know of anything that has been done in this regard, but on the
>>> face of it I cannot think of any reason that classes and methods should
>>> be objects, while method categories and class categories are just labels.
>>> 
>>> Maybe somebody should do something about that.
>>> 
>>> Dave
>>> 
>>> 
>> 
>> 
>> 
>> 
>