|
>I see
three ways this could happen, there may be more: (1) The variable "global_foo"
is truly "global" on that server from the moment it is instantiated, and remains
in memory even when there is no "running code". This is contrary to the
way I understood globals to function . . . in which case there was a
misunderstanding regarding scope, which in turn is due to lack of adequate
documentation. That is to say, it was my understanding that controllers
constitute "top level" code, and therefore when a controller exits, all
information that is "global" to that controller should be lost. If, however, a
"global" functions across controllers, effecting the whole "app", then this
makes sense . . . but should be better documented. (2) The variable "global_foo"
is supposed to be global only up to the controller context, but something went
wrong and it is getting improperly preserved. (3) The POST variables are being
improperly preserved (cached) between sessions.
>In order of decreasing liklihood, I would rank these (1), (3), (2). When I stated that this could be due to some kind of server caching, I was referring to situation (3) . . . POST variables being improperly cached. That could be tested but I do not think it is very likely. It's always remarkable to me that the people are quickest
to suspect that there's a bug in the language--not a bug in their test
code, and not a bug in the application under test.
Do you think it's more likely that Ruby preserves
the value of variables across runs, even when memory is deallocated?
Remember that the operating system would have to collaborate by preserving the
contents of whatever address the global points to.
---Michael B.
|
_______________________________________________ Wtr-general mailing list Wtr-general@rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-general
