On Wednesday 29 December 2010, Luke Plant wrote:
> On Wed, 2010-12-29 at 11:20 +0200, Shai Berger wrote:
> > On Wednesday 29 December 2010 05:24:06 Russell Keith-Magee wrote:
> > > As for "do we intend to solve this issue" -- you haven't been exactly
> > > clear as to what the issue *is* -- or rather, why it isn't already
> > > trivially solveable using completely standard OO techniques.
> >
> > The real issue, as I've seen it, is not in cases such as raised by the
> > original poster, but in cases where the code that needs the request is
> > located some distance in the call-chain below the code that has access
> > to the request; then, solving the problem in the way Russell outlined
> > involves having several places in the code which accept (and sometimes,
> > as in Russell's example, even keep) a request object only so that they
> > can pass it on.
>
> This is a general problem in all software in all programming languages.
> It is called the configurations problems (refs to Haskell), and all
> solutions have problems.
>
I didn't think to bring other languages up here, but since you have, venerable
Common Lisp has a pretty good one in dynamically-scoped variables -- they are
like thread-locals, except that their bindings are stacked rather than
desctructive, and (essentially, in translation to Python term) bindings are
popped when the function that made them returns. This gives assignments
exactly the right level of locality. But we don't seem to have those at hand.
I
> Making request a parameter of all objects/functions means that I can't
> use those functions from a non-web context. Even making it a keyword arg
> is less than desirable, because I have to alter all these functions in
> the call stack, and some of them are outside my control, and some them
> just don't have anything to do with web requests. Using threadlocals is
> bad because it introduces global variables. However, the request is (or
> ought to be treated as) an immutable global variable, which are much
> better than mutable global variables, so this solution is arguably no
> worse than the others. Another approach is callstack tracing to find a
> request object [3], which makes threadlocals look good in comparison!
>
While callstack tracing is definitely ugly, it does give the semantics of
dynamically scoped vars, which IMHO is the best possible semantics.
But euh, at what cost!
Have fun,
Shai.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
