From: Chris N. <pu...@po...> - 2001-04-20 14:22:57
|
At 10:13 -0400 2001.04.20, Patrick Galbraith wrote: >The other day, in IRC, was were talking about how Utility.pm has become >an orphanage of methods, and how it might be time to look at grouping >different methods in Utility into their own modules. One nice way of >doing this would be to have the new modules be submodules of Utility, >and be able to use Utility the same way we do now without having to >worry about what particular sub module to use (the way CGI.pm does it). >In looking at CGI.pm briefly, I notice it uses autoloader and other >means of doing this (I'm no expert on how CGI.pm is coded) How might we >go about implementing this for Utility? The implementation was already discussed briefly. We would just export things out to Slash::Utility, and then out to the caller of Slash::Utility from there. No AutoLoader. I suppose we could use AutoLoader, but I see no significant gains to be had from that. Down the road maybe we could if the Slash::Utility modules got huge, AND we did not need to use all the functions. What we probably should do is consider how we export things out. Have export tags (e.g., "use Slash::Utility qw(:content :getStatic)"), and maybe even consider not exporting anything by default. >What does it mean for memory >usage (preventing Utility to be to huge) ? Nothing at all. As noted above, if we decide it is too big, AND we will not be using the whole thing, then we could consider doing something, perhaps with AutoLoader. But if you are going to be using all the pieces of it, there's no point in AutoLoader with mod_perl. mod_perl will eventually load it all in anyway; what we really want to do is get everything loaded into the root Apache process on startup, which wouldn't work with AutoLoader. >Thoughts? Well, the thing we wanted to do was decide how to split it up. -- Chris Nandor pu...@po... http://pudge.net/ Open Source Development Network pu...@os... http://osdn.com/ |