[TransWarp] Constraints on model attributes

[Phillip J. Eby]

At 10:33 PM 7/27/03 +0200, Roché Compaan wrote:

>I started out following the pattern you describe above but as I went
>along I realised some attributes belong in the feature definition and
>not in the type definition.

Judging by your attachment, I'd have to say we disagree quite a bit on 
which is which.  IMO, your Container, Iterable, Orderable, Enumerable, 
Bool, Int, and so on are all *types* -- even MinMaxLen.  These are all 
things that are entirely independent of a structural feature.  (By the way, 
peak.model offers a built-in enumeration type, as well.)


>I agree with you though, constraints that
>have bearing on the type should be defined on the feature type. I
>rewrote Zope3's schema fields PEAK style to see how well it will work in
>PEAK. The kludgy part at the moment is validating type constraints, but
>I think this can be resolved by following the pattern you mention above.

I see no value in your Field subclass.  It adds nothing over using 
mdl_normalize method on types to do validation.

I'm wondering if perhaps the issue here is that you're assuming that a 
peak.model Type must be a class that's used for the values.  That is not 
the case; a Type exists to supply metadata (such as a parsing syntax), type 
conversion, coercion, and constraints.  Thus, I would render virtually all 
of your Attribute subclasses as Type subclasses instead, and use 
mdl_normalize methods where you have _validate methods.

I might keep the _onLink() methods in a convenient feature base if I wanted 
to be able to implement constraints, but I think I'd rather focus attention 
on *object*-level constraints, and perhaps an object-level validation.

Indeed, I wonder if maybe peak.model should offer an object-level 
validation hook, that gets called before an object's state can be flushed 
to storage.  If this hook were also callable by UI frameworks, they could 
simply set all values as desired, call the validation hook to get a list of 
problems, and roll back the transaction.