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".

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.

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
>>
>>
>
>
>
>