Hi Chris,
On Aug 18, 2018, at 10:12 AM, 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. 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@gmail.com wrote:
On Aug 18, 2018, at 6:02 AM, karl ramberg karlramberg@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@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@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