[PEAK] peak.model and mappings?

[Phillip J. Eby]

At 03:42 AM 2/24/04 -0500, Bob Ippolito wrote:

>Here is my first pass at extending StructuralFeature and friends to 
>support mappings...
>
>It would be great if someone (PJE, preferably) could take a look at it and 
>let me know if I'm going in the right direction here.. I'm still new to PEAK :)

ImmutableDict has a bug: equal instances do not necessarily have the same 
hash, if they are created from the same sequence of items, but in a 
different order.  (Also, it's not really immutable since you can call 
__init__ on an instance to modify its contents.)

FYI, 'NewFeatureClass' is unnecessary; all of its attributes can be defined 
in NewStructuralFeature, wrapped by 'binding.classAttr()'.  The only reason 
FeatureClass doesn't do this is because there are so many it'd be tedious.

Your approach to getting superclass methods is interesting.  I wonder if 
it's the only way to do it.  I haven't really done much with the 
MethodExporter stuff in a long while so I don't recall right off if there 
are any easier ways to do it.

I imagine you wrote this the way you did with the intention of folding it 
back into StructuralFeature; otherwise it would've been simpler to start 
with an assumption that 'isMapping' is in effect.  Earlier predecessors to 
peak.model had very different subclasses for the different implementations 
needed for isMany-checking.  They were combined only because it made code 
generation from MOF models easier.  IOW, the peak.model core is designed 
for MOF alignment, so its metamodel matches that of MOF.  MOF calls for 
features to be singular or plural by dint of their upper/lower bounds, so 
that's why peak.model does it that way.  It's not because there's some 
really good reason (that I know of, anyway) to do it like that.

So, probably if I did incorporate a mapping type into peak.model, it 
wouldn't be part of StructuralFeature's core behavior, for the simple 
reason that the MOF model doesn't support it, which means having the 
extensions in StructuralFeature wouldn't be worth the pain of adding so 
many alternate branches to the code.  Sorry to put you through the pain of 
writing it that way, but your first note said you were just doing a 
subclass.  :)

Anyway, it basically looks good, though I haven't delved into the logic of 
each and every verb.  I'm also not sure about the reuse of the link/unlink 
notification stuff to pass keys instead of item positions, but it seems 
like a reasonable extension.

Fair warning, though...  peak.model will probably undergo some refactoring 
this year to take advantage of peak.query and peak.events.  Right now, the 
link/unlink notifications go only to the feature object, which isn't very 
useful for integrating with GUIs, business rules, etc.  Features need to be 
more like events.Value() objects, that can have observers.  This will allow 
rules, persistence, and GUIs to integrate without needing explicit support 
in the domain model code.