eliot.miranda at gmail.com
Sat Aug 18 17:31:55 UTC 2018
> 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
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.
>>> 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:
>>>>>> 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.
More information about the Squeak-dev