Chris, these are good arguments.

For who ever used VW refactoring browser, the answer is obvious: if
comment was accessible from class browser, then it would enable
browsing and discovering what is in the image, and it is IMHO
invaluable.

As for small production image, there's not much difference with class
comments, and there should be less package than classes...

Nicolas

2012/7/29 Chris Muller <asqueaker at gmail.com>:
> On Sun, Jul 29, 2012 at 1:39 PM, Bert Freudenberg <bert at freudenbergs.de> wrote:
>> 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.
>
> Never said that.  When I said "the Compiler via the code browser" I
> was not proposing a solution to anything, it was a way of trying to
> ask, "what are your requirements here?".
>
>> 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.
>
> You keep proposing "solutions" for updating package information but
> never clearly stated the context in which one would want to consume
> that information.  Presumably, by the time someone gets to the point
> of dealing with a single MCZ, they're typically already past the point
> of "discovery" about the package and ready to install.  Under what
> scenario does someone find a general comment about the package useful
> at this stage?
>
> Unless...  you're thinking you to use MC for the discovery
> requirement.  But the SM Catalog is more ideal to satisfy the
> "discovery" and "installation" requirements because it's agnostic
> about the underlying package solution being used.
>
> I can describe another scenario.  Perhaps someone likes their
> production system to be as small as possible, and so they might prefer
> package verbiage and documentation not forced to be bundled with the
> code, which is all they really want installed in the prod server...
>
>> 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.
>
> What else shouldn't a "normal" developer not have to know?
>