Re: PEAR2 wiki document

Travis Swicegood wrote: > On Aug 26, 2007, at 2:42 PM, Gregory Beaver wrote: > >> Travis Swicegood wrote: >>> Re: Namespaces and package names: >>> >>> I'm not thrilled with mixing _ and ::. Using PEAR2_HTTP_Request to >>> install PEAR2::HTTP::Request doesn't make sense to me. I would much >>> rather see it as pyrus install PEAR2::HTTP::Request. I'm not sure I >>> see the reason to use underscores in place of double-colons within the >>> name other than BC which PEAR2 hasn't been worried with thus far. >> This bothers me as well. Namespaces as a possibility is so new, I would >> like to reserve judgement on this one, we will have a number of months >> left before the first alpha release of pyrus when the decision must >> be made. > > Fair enough... Is there a roadmap with timelines on it yet? :-) No - we need to wait for the PHP internals team to decide whether to backport namespaces to PHP 5.3 or not, then we can set a timeframe. > Assuming pear.example.com used Example as their namespace. Declaring > the namespace would then be a case of modifying channel.xml to include: > <name>pear.example.com</name> > <namespace>Example</namespace> > > Once it's discovered, nothing else could use the namespace Example > without displaying an error. If a server changed, that would display > an error as well. The namespace, which would be kept internally with > the channel name, would then just route everything the way an alias > does. It would also be the assumption that "pyrus install > Example::SomePackage" would be the equivalent in today's PEAR as "pear > install example/Example_SomePackage". Again, the assumption is made > that Example_SomePackage would be replaced with Example::SomePackage. > > I'm not sure I see any way to circumvent such a setup without having > access to change the internal config/registry files for a given PEAR > install. If someone who shouldn't have access to those managed to do > that and make changes, there's bigger issues at that point. The current system of <suggestedalias> is like your namespace tag, but allows the user to "import" a namespace through the "pear channel-alias" command and is in fact closer to the idealized namespace implementation than your proposal ;). Seriously though, I am not convinced there is a compelling reason to change this system to make it more restrictive. >>> Re: Class to file naming exceptions: >>> I'm not a fan of any exceptions to the rule - I just don't see a need >>> for anything installed in @php_dir@ to not following >>> Example/Package/Class.php naming. If there's a valid case where that >>> exception should live, I'm happy to listen. >> No one is a fan of it, but allowing a case that no one has thought of to >> be specially approved by a vote of the governing body of PEAR provides a >> loophole that means we are stringent but not inflexible. >> >> In other words, it makes it very easy to adhere to name=>file rule, and >> very annoyingly hard to get an exception. > > Fair enough... Maybe it should be reworded to say something to the > effect "exceptions will be made on a case-by-case basis and only after > extraordinary evidence is shown to prove that an exception should be > made in that case" :-D Because the exception must be approved by the PEAR Group, which is an incredibly conservative bunch of folks when it comes to coding standards, I think this is implicit. >>> Re: Loading all files at once: >>> I would remove the dirname(__FILE__) in favor of a package level >>> constant. If NS'd constants can be declared with functions in them (a >>> la define()), then I would at an Namespace::Package::path = >>> dirname(__FILE__), then use "require Namespace::Package::path . >>> '/Class.php';". If namespaced constants go the way of class >>> constants, then I would follow the Super_Long_Package_Name convention >>> and specify that each package should define "Example_Package_path" (or >>> some similarly named constant) to avoid the repetitive >>> dirname(__FILE__) calls. >> You can do whatever you like in allfiles.php, this is in the language. >> It is a black box that after including has loaded all needed files. > > I think allfiles needs to be generated. As has been pointed out > several times, its easy enough to do programatically, so why add to > the developers troubles by making it a required check-in. I'll put > together one for phing... Sounds fine to me. I would prefer that the packager generate it if one doesn't already exist, or if requested. Phing as an option for packaging would be interesting to some folks (if you want to write it and maintain it). >>> Re: if(!class_exists('SomeClass', true)) >>> Is this a requirement that they be declared at the top, or just a >>> suggestion for people who want to add them? In the tests that I ran >>> back in June, it appeared that the if statement ate up a large chunk >>> of the benefit of not doing require_once everywhere. I would be for >>> making this a suggestion for people interested in documenting, or >>> provide some sort of annotation in a docblock that can be checked by >>> pyrus, phing, etc. >> If the file is already loaded, there is no performance difference. > > I'm going to have to disagree here. There is an if() that wouldn't > normally be there along with an invocation of class_exists() that > wouldn't be. class_exists() might be faster than the stat on the file > system on some platforms, but there is a performance hit. > > All that said, I've been coding with an autoloader for the last few > months on my pet projects and so far it's working great. I saw your blog posts. It will be interesting to follow. As for the performance difference, I ran a quick ab test, and do find a slight degradation in performance when if (!class_exists()) is used (988-1000 req/sec for if(!class_exists()) as opposed to 995-1012 req/sec for require_once and 1108-1141 req/sec for straight class usage all without APC). So, it looks like ~12% difference in performance between if (!class_exists()) and straight class usage, and again ~11% difference in performance between require_once and straight class usage. Because class_exists() can't be opcode cached, this performance difference is present even with APC. This leads me to believe that perhaps class_exists() is not a solution, and the only solution that is both flexible and fast is the doc comment at the top of the file needs to document where to find required classes, and the coding standard should be updated to reflect this. Greg