Re: [Modeling-users] ModelMasons refactored

[Sebastien B. <sbi...@us...>]

Mario Ruggier <ma...@ru...> writes:
> >> A propos de previous post on KeyValueCoding names -- this proposition
> >> lacks a minor thing, and that is inside the __init__ body, the
> >> attribute values should be set using KeyValueCoding, not to bypass any
> >> custom code in the get/set methods for each attribute.
> >
> > That's questionable. KVC mechanisms are handy, but
> > time-consuming. Moreover, I'd like to keep as little modeling-specific
> > things in the generated code as possible --for the moment being there
> > are Modeling.CustomObject  in the inheritance tree, and
> > willRead()/willChange() methods [1].
> >
> >   I'd recommend self.setAtt1(att1) in __init__() rather than
> >   self.takeValueForKey(att1, 'att1') in this case.
>=20
> Yes, you are right ;)
>=20
> Since last night, i've rethought my little proposal, and I would
> now be against it because of (a) if it is done this way, custom property
> logic should not be bypassed in my opinion, and (b) if a KVC loop
> is to be performed each time any CustomObj is initialised, the
> performance price is too high.
>=20
> But, how about this little compromise, as a utility function that
> can be used only when needed:
>=20
> def updateCustomObject(co,**kwargs):
>      for k in kwargs.keys():
>          co.setValueForKey(kwargs[k],k)
>      return co
>=20
> It receives an instance =3D=3D>> can be used on new objects
> (instantiated on the call) as well as existing instances.

No problem w/ this. We just have to decide where it should be put! (module
CustomObject?)

[snip]
> I had not realised that __slots__ implied also these other things.
> So this can be put on hold, for possible future consideration.

BTW if someone on this list uses new-style classes and slots regularly plea=
se
email me privately, I have some questions about it --I'll summarize the
situation here afterwards.

> > [1] I'm currently working on a integrating the framework w/ the ZODB
> >     framework. In this configuration willRead/willChange methods
> >     disappears, and CustomObject inherits from ZODB's Persistent class.
> >     I'll make a branch and an alpha release as soon as possible.
>=20
> Any implications for those not using ZODB?

  Not in a near future, no need to worry. The goals underneath are:

- use ZODB.Persistent, because of the (C) extension class is *much* faster =
wrt
  detecting that an object has changed (additionally, it make it possible to
  transparently detect this, no willChange() needed anymore),

- bind the framework (esp. the EC fonctionalities) to the ZODB's transaction
  machinery.

  After release, the two versions will be maintained in parallel, and as far
  as I'm concerned the current version won't be deprecated unless we reach =
the
  point where noone uses it!

  I'll make all this clearer in the long-term planning that Soif requested =
and
  that I'll try to submit here soon.

        Cheers,

-- S=E9bastien.