Re: [Modeling-users] ModelMasons refactored

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

Sebastien Bigaret <sbi...@us...> writes:

> Ok, I think we have a problem here w/ the 'base' generation
> scheme. Consider you modify the StoreEmployees model so that the classes
> Employee, Executive and SalesClerk are in the same module
> 'Employees'. This would generate:
[snip]
>   The problem? It creates an import loop between packages StoreEmployees
>   and StoreEmployees.MDL, and worse, another one between modules
>   Employees and MDL.Employees (this problem remains even if we forget
>   about the 'MDL' sub-directory and when all files are dropped within
>   the same package).
>=20
>   If someone has a solution for this, please share!
>
>   I have the feeling that it is enough to state that a class and its
>   subclass(es) should *not* share the same module when the 'base'
>   generation scheme is involved. What do you think?

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.

  This constraint is not implemented yet.

To retrieve the branch: in directory ModelMasons, directly type:

    $ cvs update -r brch-0_9pre6-1-ModelMasons_base_generation_scheme


  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.

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?

    Happy testing!

-- S=E9bastien.