Stas Bekman wrote:
I don't have much to comment on these issues. I'm not going to repeat again and again why the separation into multiple modules is important.
I don't think anyone would have a problem with the multiple files, if we can just hide that unexpected complexity from end users.
+1
It may be unimportant to many users, but we aren't going to take it away from those who need the ultimate performance.
My suggestion about autoloading would not take away anyone's ability to preload things. It would help people who are not sure what they need yet though, and avoid worrying about what to preload until you are ready to do performance tuning.
please re-read my reply to this earlier suggestion of yours. In order to use AUTOLOAD'ing you need to load that module that contains the wrappers first. It [Apache::RequestRec] is not loaded by default and it won't be loaded by default because it is not always needed. That means that the user still needs to load something. And that's where my wrapper suggestion [Apache::whatever] comes in.
Granted we want to make simple things easy and complicated possible. And that's exactly why I've suggested to create another easy layer for those users who don't care about saving a few msecs here and there and don't care about a few hundreds extra k's of memory wasted. Why don't you like that suggestion?
Because it's not transparent. People still have to think about what they are going to load in a very early stage, and they still need to know which files (or import sets) the methods they call on $r are defined in. If they get it wrong, their program will die.
IF they call preload_all_modules() at the server startup, it'll just work.
It also doesn't address the docs issue.
That's a good point. But this is an easy problem to solve. For example, methods in other manpages can be cross referenced. e.g.:
Apache::RequestRec TOC Methods living in this package ... Apache::RequestRec Methods living in other packages ... ...
I'm sure we can come up with some other good ideas.
OF course what you seem to be advocating is to throw all Apache::RequestRec Methods in one package and therefore it solves the loading problem and the documenation at once.
With an autoload scheme, we can have a little app that tells you what to add to your startup.pl when tuning or we can have a flag that prints that info to the error log when it autoloads something. People can feel comfortable with the fact that their app will still work if they forget to preload something.
You want to preload all modules, go for it.
I think that would be a better default than the current scenario, at least for $r (load everything by default, and have import options that load specific things instead), but autoload seems like a better compromise. And this doesn't address the docs issue either.
Where do you put the limit? You suggest to load all modules for $r, but many modperl modules need many other modules, to work on $s, etc. You have one need someone else will have another need for what needs to be loaded by default. I see no better solution than loading everything by default and having a config option which will prevent this from happening. So you will start with a working mp2 no matter what, just like it was mostly for mp1 (minus several modules that you *did* have to load before you could use them, like Apache::Log)
Is there a technical reason why autoloading the $r methods wouldn't work?
IMHO, there is no need for it. You either want to fine tune and you load only what you need. Or you don't care and you load them all. I fail to see why do we need to complicate things any further.
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
