On 29.07.2012, at 14:01, Chris Muller wrote:

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

So if I understand you correctly, you think adding a comment and license to PackageInfo is not necessary, because you rather want to add that to SqueakMap or some other tool. Fair point. I just don't understand why you were proposing PackageInfo subclasses before. I'm just saying that *if* we want to add package metadata that is versioned by Monticello, then adding that to the PI instance is better than relying on subclassing. Whether we need the whole thing I don't know, we've been living fine without for years, but it sounded like there are people who think it would be a good idea to have it. 

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

Now you're just teasing ;) There is a huge difference between experts and newbies, but "normal" developers in between these extremes can still be productive. There are many details about the system which less experienced developers do not know about, too many to list really. Or are you constantly thinking about what exactly happens when you press a key or click a mouse button?  

- Bert -