Re: [Modeling-users] ModelMasons refactored

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

        Hi all,

I wrote:
> [...]
> I've just finished a first proposal for this and committed it under the
> branch tagged brch-0_9pre6-1. It solves the problem as long as a class
> does not share the same module than one of its (direct or indirect)
> subclasses.
>=20
>   This constraint is not implemented yet.
>=20
> To retrieve the branch: in directory ModelMasons, directly type:
>=20
>     $ cvs update -r brch-0_9pre6-1-ModelMasons_base_generation_scheme
>=20
>=20
>   I successfully applied this on models AuthorBooks and StoreEmployees,
>   it would be cool if sb. could check that on his own projects. I also
>   did not pay a very close attention to the generated code (I just made
>   sure it works out-of-the-box wrt the tests), hence there can be
>   repetitions, useless portion of codes, etc. in the generated modules.

The constraint for 'base' generation scheme is now implemented in the
branch.

If nobody has more comments/requests/critics on this, this will be
integrated into the main trunk today or tomorrow and the brch will be
closed.

> BTW: Mario proposed that the generated class initializer could be:
> >   def __init__(self,att1=3DNone,att2=3DNone):
> instead of
> >   def __init__(self):
>=20
>   Are we ok we go for it?

I'm too lazy to change this now; Mario also posted an alternate:
> 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

  -> still needs to be done. Maybe this can be a FAQ entry in the
     meantime.

-- S=E9bastien.