On Sun, Jul 29, 2012 at 1:39 PM, Bert Freudenberg bert@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?