Agree with Dale. The normal way to create a new package is by pressing a button in Monticello, not having to write a PackageInfo subclass. Subclassing should only be necessary to override the actual behavior. But storing strings as source code is not changing behavior. Besides, it just feels wrong e.g. having to escape quotes in the string.

We do need a better tool for editing packages, agreed. But editing a comment in that tool should not have to generate a method. It should just store the comment in the package object. Same goes for other attributes such as license that we agree upon should be declared at a package level.

Chris, I don't know where you got the idea that subclassing PackageInfo is a good thing, but it surely is not what the vast majority of package authors have been doing. The best way to get more package metadata into our packages IMHO is adding these fields to PackageInfo and making a nice tool to edit them.

E.g., Monticello's button to add a package could pop open a Package Editor dialog where you fill out the name, license, comment etc. fields for the new package. Straightforward, and even in-the-face.

Compared to that, having to know about making a PackageInfo subclass, thinking where to put it, remembering to override the right methods, that sounds way more obscure, wouldn't you agree? I bet many "normal" developers don't even know what PackageInfo is, and they shouldn't have to.

- Bert -


On 29.07.2012, at 10:33, Dale Henrichs wrote:

> It seems a bit much to require the creation of a subclass of PackageInfo for your project just to supply a package comment ... 
> 
> I understand your point that without tool support it's kind of a moot point... the tool (whatever and where ever it may be) will probably drive the question of "where to store the comment":
> 
>  - do you crack the zip file to get the comment?
>  - do you crack the zip file and reify the definitions?
>  - something else?
> 
> If you have a package comment it would make sense to display the comment on SqueakSource, SqueakMap, in the image, etc....
> 
> Dale
> 
> ----- Original Message -----
> | From: "Chris Muller" <ma.chris.m at gmail.com>
> | To: "Dale Henrichs" <dhenrich at vmware.com>
> | Cc: "The general-purpose Squeak developers list" <squeak-dev at lists.squeakfoundation.org>
> | Sent: Sunday, July 29, 2012 10:05:20 AM
> | Subject: Re: [squeak-dev] Documentation/Comment per package
> | 
> | > You have to agree that a `package comment` belongs with the package
> | > and should travel where ever the package goes ...
> | 
> | Yeah that's a good responsibility for a PackageInfo, but until I
> | understand how it would interplay with IDE tools in a useful way,
> | simply a message implementation seems enough.
> | 
> |     PackageInfo>>#comment
> |          ^ String empty
> | 
> | and subclasses can override if they wish.
> | 
> | With this approach you get all the comment versioning / diffing etc.
> | for "free" vs. Berts approach the comment is a "special" attribute of
> | the PI that is "hidden" from all of the other attributes such as
> | #license, #authors, #tutorial, etc.  For THOSE attributes, go to the
> | PackageInfo class browser and update them, but for the #comment, go
> | somewhere else because it's stored in a MC definition.
> | 
> | So, it's an inconsistent treatment of PI attributes that I have
> | trouble understanding why and would not want to try to explain to a
> | newbie..
> | 
> | Regards,
> |   Chris
> | 
>