Hi, Dag Sverre Seljebotn wrote: > Basically, write encapsulated, stand-alone code that can be unit-tested > easily, > and don't assume that the compiler works this or that way (ie, the transform > shouldn't have knowledge about various phase > > What it does need knowledge about is what kind of contract/state the tree is > in: > "I expect there to be type information there"), which is something different > from "I know there will be type information there because we are in state B > or C > or D but not A". The former is a contract, the latter makes the transform > assume > something about the compiler operation.
I generally agree with the IoC principle, however, the current way of using cmd line options is pretty much out of question. So, yes, plugins should register themselves, and they should register for a specific state of the tree. I expect that to mean: before or after type analysis (i.e. the plugin either depends on types being analysed, does not depend on types being known or does its own stuff to analyse types), or before or after generating code for the node (i.e. the plugin has to add code to the output). I think that state should be reflected by the syntax tree, so it should be possible to avoid having plugins that have to do stuff before *and* after phases (although that might still lead to a cleaner design - not sure). If you want to distinguish between a contract and a compiler phase here, fine. I think the type analysis case makes for some fine contract, and the code generation just isn't a contract, it's a phase. You'll likely need both. Stefan _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
