Re: [Modeling-users] ModelMasons refactored

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

Mario Ruggier <ma...@ru...> writes:
> On mardi, avr 22, 2003, at 15:15 Europe/Amsterdam, Mario Ruggier wrote:
> > On mardi, avr 22, 2003, at 14:07 Europe/Amsterdam, Sebastien Bigaret wr=
ote:
> >> Mario Ruggier <ma...@ru...> writes:
>=20
> [snip]
>=20
> >>>> BTW: Mario proposed that the generated class initializer could be:
> >>>>>   def __init__(self,att1=3DNone,att2=3DNone):
> >>>> instead of
> >>>>>   def __init__(self):
> >>>>
> >>>>   Are we ok we go for it?
>=20
> 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.

> Additional proposal ;)
> How about adding __slots__ to all custom objects?
> It seems to me that this is exactly the kind of usage that this was
> intended for, and will reduce memory usage for cases of *many*
> instances of custom objects. Works only for 2.2, but if present should
> not affect 2.1 instances in any way.

Could you be more specific? I can't see how slots reduce the memory
footprint.

More on slots: the framework cannot handle them out-of-the-box right
now, I can see the following problems:

  a. when an EC records an object (either insert or fetch), it weakrefs
     itself and assigns the weakref to the object (see
     EC.recordObject()) --> this implies that CustomObject must be
     turned into a new-style class in py2.2, defining __slots__ as well.
=20=20
  b. Such an object cannot be weakly references, unless CustomObject
     adds '__weakref__' in its slots.
=20=20
  c. An object using slots has no __dict__

[See also: http://www.python.org/2.2.2/descrintro.html for a complete
 discussion on csqs. of using slots]

a. and b. can be easily solved. However c. is more problematic; this is
an issue that should carefully examined (the impact is on KVC, mainly],
I'm not clear at all on this by now (I've never used new style classes
until now).


-- S=E9bastien.


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