This past September, Phillip Eby and I discussed a variety of ZConfig issues on one list or another. Two particular issues I've thought more about, and think I'm reversing myself on them. ;-)
I'm going to describe each issue in a separate email, including why I've changed my mind about them and what the consequences are for ZConfig users. Please respond to these messages if you think the proposed changes will have a negative impact on working code.
"Inheritance" of the datatype when extending a section type -----------------------------------------------------------
Currently, ZConfig section types that "extend" another do not inherit the datatype of the type they extend. Phillip argued that, at least for schema extensions, the datatype should be inherited from the base schema.
I thought it better to explicity request the same datatype was a better approach because of way we've been using ZConfig in some of the core packages. Each concrete section type really uses a different datatype; sharing configuration handling is accomplished only within Python. When this is the only way section types are being used, explicit is the only way to do things.
While trying to create some fairly basic section types that are easy to specialize using extension, this can be less than desirable. What it boils down to is that it's difficult to create section types that can be easily specialized with a minimum of additional information in the schema; a fair bit of boilerplate is needed to change a small amount of behavior.
If we add inheritance of the datatype for section types, this affects only section types that extend another section type where the "base" specifies a datatype and the derived type does not; in that case, the datatype of the base will be used instead of the "null" datatype. If the "null" datatype is needed, section types that expect it to be used can add the attribute datatype="null" to achieve the current effect (in fact, that works now).
No existing unit tests are affected.
-Fred
On Mon, 2003-12-29 at 00:12, Fred L. Drake, Jr. wrote:
I'm going to describe each issue in a separate email, including why I've changed my mind about them and what the consequences are for ZConfig users. Please respond to these messages if you think the proposed changes will have a negative impact on working code.
Cool. I'll comment, and then post a separate message about some things I'd like to see in ZConfig. (Fred created a wiki on zope.org but wikis were broken there and I don't know if they've been fixed.)
FTR, of course I'm using ZConfig in various Zope projects that I work on, but I'm also going to be using ZConfig in Mailman 3.
I thought it better to explicity request the same datatype was a better approach because of way we've been using ZConfig in some of the core packages. Each concrete section type really uses a different datatype; sharing configuration handling is accomplished only within Python.
This is how I'm using extended section types in my code currently. The proposed change won't affect me because I explicitly specify the data types in derived section types. It seems to me unlikely that you'd have a base section type with a non-default data type, with derived section types that rely on the default data type.
+0
-Barry
At 12:04 PM 12/29/03 -0500, Barry Warsaw wrote:
This is how I'm using extended section types in my code currently. The proposed change won't affect me because I explicitly specify the data types in derived section types. It seems to me unlikely that you'd have a base section type with a non-default data type, with derived section types that rely on the default data type.
Yes, it would only be useful if you could also override existing attribute or key definitions in the derived section type. Adding new attributes, but leaving the section's datatype alone wouldn't make much sense.
+0
Agreed, unless there's also a way to override/replace existing attributes, as opposed to merely adding new ones.
-
Barry Warsaw -
Fred L. Drake, Jr. -
Phillip J. Eby