[Zope3-checkins] CVS: Zope3/src/zope/schema/tests - test_datetime.py:1.3 test_floatfield.py:1.3 test_intfield.py:1.3 test_strfield.py:1.3

[Fred L. Drake, Jr.]

[Added zope3-dev to the list of recipients.]

I made some changes to the zope.schema package yesterday, and Martijn
Faassen has some questions about those.  His questions were initially
sent to the zope3-checkins list, but more people may be interested.

My checkin comment:
 > - Introduce new field types: IEnumeratedTextLine, IEnumeratedInt,
 >   IEnumeratedFloat, IEnumeratedDatetime; these should be used any time
 >   the allowed_values option for a field is used, instead of requiring
 >   the base field type to support it.
 >
 > - Updated tests, docstrings, to reflect future removal of the
 >   IValueSet "mixin" interface from ITextLine, IInt, IField, IDatetime,
 >   and several others where it simply doesn't make sense.

Martijn wrote:
 > Did I miss the discussion about this change?

No; I should have brought this up on the list before inflicting it on
everyone so suddenly, for which I apologize.

 >                                           It makes it harder to switch from
 > a field where value entry is restricted to one where it is unrestricted.
 > 'allowed_values' can certainly be seen as a constraint on a field instead of
 > as an entirely new field type. I'd like to get a bit more detail about what
 > motivated this change.

Yes, allowed_values is a constraint on a field value.  Lots of things
are, including the basic type information.

I'm not sure what you mean "makes it harder".  In terms of the number
of actions required to make the edit, it means changing the schema
involves 1) removing an allowed_values argument to the field
constructor, and 2) changing the name of the field type.  Yes, there's
a little more than removing/commenting out the allowed_values
argument, so it could be seen as "harder".

As I'm sure you understand, the biggest aspect of schema change is
proper support for the new schema in the application, and when
expanding the set of allowed values for a field, the hardest part is
ensuring the code has been tested thoroughly and that edge cases are
properly located and checked.  There's far more than making a couple
of edits to spelling of the schema.

You don't state whether you're interested in changing schema for
projects during they're initial development or during maintenance of a
production application.  I can only guess which is your primary
concern, but my take on this is that the real difficulties surrounding
schema evolution involve testing application support and migrating
data that may need to change in some way.

There's a lot more to say about schema evolution, but it really isn't
Zope-specific, and on re-reading your comments, doesn't really pertain
to your specific concerns (relaxing constraints, rather than
tightening them).

My checkin comment:
 > Rename IValueSet to IEnumerated, and ValueSet to Enumerated.
 > Treat these more like mixins than like directly useful things.

Martijn Faassen wrote:
 > Why do you consider the word 'Enumerated' better here? 'Enumerated'
 > to me implies giving each entry in some list a unique (increasing) 
 > number. 'ValueSet' is not incredibly better, but at least 'Value' doesn't
 > imply (integer) numbers as much as 'Enumerated' does.

I'll start by noting that "Enumerated" doesn't make me think of the
assignment of small integers; "enum" would, but I didn't use that on
purpose.  "Enumerated" really tells me that the value must come from a
pre-defined list of allowed values, which is exactly what we mean.

"ValueSet" doesn't tell me that at all.  It makes me think that the
value is actually a set of values, and that's not what these types
are.  You could reasonably argue with my interpretation of this,
however.

I think "Enumerated" is a better name than "ValueSet" largely because
Enumerated is an adjective, and adjectives make more sense as mixin
names.  The way things are arranged (including before my changes)
makes me think that it was intended to "mix-in" additional behavior
(in the implementation) or to modify the semantic description (in the
interfaces), which is definately an application of mixins.


  -Fred

-- 
Fred L. Drake, Jr.  <fred at zope.com>
PythonLabs at Zope Corporation