[Zope3-dev] Re: [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

[Steve Alexander]

Fred L. Drake, Jr. wrote:
> [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 own code depends on the stuff you changed, so I'm very interested in 
this. (It means I need to alter my code.)
I have my own field types that derive (in implementation) and extend (in 
interface) from the ones in zope.schema.


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

I was going to make a similar change to this field type.
However, rather than make a different implementation class, I was going 
to use the same implementation class, and have instances change their 
own interface declaration depending on whether allowed_values is defined.

This allows you to use a different widget for an any-values fields to 
the one used for an allowed-values field.

Other than this change of constraint, I see no problem with the same 
implementation being used. I see no more problem with changing an 
allowed_values constraint on a Field instance than with changing any 
other constraint on a Field instance.


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

Do you propose disallowing any other changes to the notional set of 
valid values for a field?

Do you want Field instances to be immutable?


> I think "Enumerated" is a better name than "ValueSet"...

I too prefer Enumerated to ValueSet.

--
Steve Alexander