> I wouldn't use this approach for any module declaring classes of any
> objects that persisted beyond a single request. Then again, I probably
> wouldn't use reload() in that case, either. ;-) But it seems to work
> nicely for PTL modules and UI classes that define throwaway objects.
>
> ...
>
> -- Graham


I ran smack into this problem... My design style (evidently) is different
from yours, making the reloading of modules tricky, and not something that
can just be tacked on as an afterthought.

I tend to use Quixote to publish object namespaces, rather than module
namespaces (with the exception of the root, which is a package).  As a
result, I am almost always picky about what I import where; I use from x
import y, z...  This makes reloading the module just about useless.
Further, I generally have objects that survive the page request, so even if
I reload the class def, my old copy of the class is still based on the old
code, and will be until I recreate it.  I never do, in some instances.  I
expect it to be created at app start up, and be available from then on.

The 'solution' I've used so far is to have a Restart link available in my
apps that tells the app to exit.  FastCGI takes care of actually restarting
it for me.  It's not perfect, which is why I was excited over your idea.
(I'm persisting session info to disk, so it works out ok.)

Unfortunaely, due to my approach, Neil's idea isn't immediately useful to
me, either (I'd still have to recreate my objects).

I think what it boils down to is that my design approach just isn't 'dynamic
source code' friendly.

It has been educational working with this, and I may try some experiments
with a more module-namespace approach in the future.  I just felt it was a
mite cumbersome to map UI concepts directly to modules/packages, but very
easy to map them to class instances.

Jason