[Zope3-Users] Set & List constraints

[Markus Kemmerling]

Am 10.07.2008 um 21:56 schrieb Tim Cook:

>
> On Thu, 2008-07-10 at 16:59 +0200, Markus Kemmerling wrote:
>
>> I would rather say:
>>
>> value=List(
>>    title=u"Value",
>>    value_type=Object(schema=IMyClass)
>> )
>
> Can you elaborate why?

You want to restrict the elements of a list to instances that provide  
a given interface IMyClass, right? That's exactly what a field's  
value_type attribute is for: It validates every element in a sequence  
or, more generally, a collection, before setting it. When you set the  
value_type to Object(schema=IMyClass) a validation error,  
SchemaNotProvided, will be raised for every list element not  
providing IMyClass (which in turn will raise a WrongContainedType  
error for the list itself).

The (rarely used) classProvides you used in your code example:

> value=List(
>   title=u"Value",
>   constraint=classProvides(IMyClass)
> )


is meant to be used in class definitions to declare that a class  
itself -- not is instances -- provides a given interface.

>> Anyhow, such a constraint is of limited use only, since it does not
>> prevent you from adding any object you like to the list *after* it
>> got assigned to the 'value' attribute.
>
> Okay, but that would be badly behaved code; correct?

Probably.  But then I would consider using a tuple instead of a list  
(and a frozenset instead of a set).

> In my implementation I am creating instances and committing them to a
> ZODB repository.   My thoughts were that copies of those instances  
> would
> continue to constrain the types allowed in that attribute.  Is that
> incorrect?

I am not sure if I get this. If you set an instance of a mutable type  
like a list as an attribute of some other instance described by a  
schema, it will be validated, but still remain mutable (finally your  
other object only holds a reference to your mutable). It doesn't  
matter if it is persistent or not, or if it was copied before. But I  
might misunderstand your intention here.

Regards,
Markus Kemmerling