On Tue, 2004-01-20 at 15:09, Stas Bekman wrote: > > Good. Do you think there should be a separate module for this, that > > just acts a shell for $r and AUTOLOADs other things? That would avoid > > loading Apache::RequestRec unless it is needed. Apache::RequestHandle > > maybe? > > You don't necessarily need a module for that. All you want to do is to install > > sub Apache::RequestRec::AUTOLOAD, with a few lines of code.
Why do it in a strange way? Why not simply have a normal module? It's easier to maintain if things live in the most obvious place. > That's exactly the problem. There are many cases where we don't pass $r > explicitly but you can always get it via $r->server or $f->server, or > Apache->server. So it's quite possible that the only solution is to always > have this hook/wrapper preloaded. These should all return exactly the same thing as when you get passed $r, so they will all know how to AUTOLOAD. > BTW, inside a filter you can do $filter->r. Do you suggest that we change that > accessor to install the wrapper too? See above. > Do you see what I meant by saying that you need to look beyond the mp1-like $r > usage. Not really. Sorry. > But there are many other objects returned by mp2 API, beyong $r, $s and $c. > what about them? They should all work the same way. Users should never have to explicitly load a module just to allow them to call a method on an object they already have. > See, this is your "problem" - mp2 is much more than $r and $s. But you want to > fix only those because you don't know about the others. We here try to have it > right and homogenious for the whole API. So people who will want to use mp2 > just to write filters won't say, why $r is easy but $f is not? Good question. Why wouldn't we do the same thing with $f, and any others that I don't know about? - Perrin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
