On Sun, 2011-02-27 at 11:31 -0800, nan wich wrote: > Ah, see now you say that 10% of hook_init's are appropriate, so > telling someone to always avoid it is bad advice. In all the coding > that I have done, I have used hook_init() maybe three times (twice I > know for sure). And one was largely a toss up between hook_init() and > hook_boot() and I can guarantee was needed. And you probably add > hook_exit() to the list of questionable usage.
Don't make me say something I didn't mean. What I really meant is that hook_init() should never be used, some modules legally uses it as a way to set up some context related information because no other helpers exists in core (that's actually part of the butler project on g.d.o). But aside of that, all hook_init() implementations should be banned. In fact even existing one (I'm thinking about D6 OG module) can show themselves being incredibly slow under certain circumstances. > In the case where I created my own cache file, it was more an attempt > to "help" the database keep the data available because rebuilding the > data (taxonomy-based) could get quite heavy in certain circumstances. > When I convert the module to D7, I may not need any of that because > field data may already be cached any way. As a matter of fact, 90% of > the module may no longer be needed. If you choose to separate your own cache for logic and business reasons, this is totally valid. For actual D7 core implementation, I'm not sure fields are cached, that's something that the entity API attempt to resolve. They didn't figure out a nice way to do it in core before the D7 release. Pierre.
