Actually, reading that article it gives the wrong impression, that is not what I meant.Also, it kinds of breaks IoC: http://en.wikipedia.org/wiki/Inversion_of_Control It's strange that it is called IoC - it might be the inverse of 1980-s style programming, but it certainly is the norm now. The important thing anyway is about encapsulation and the so-called Hollywood Principle -- "don't call us, we will call you" (to cite the article). 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. The assert I inserted contradicts this and was a quick mistake BTW :-) -- Dag Sverre |
_______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
