basic issue with ScriptReorganizer and pharize

Hi, I don't know what is up with the news server, this is 2 days in a row of connection refused, but I am reading through theaimsgroup and saw a message from Stephan Rausch that said:

Do you also mean that decorators *HAVE* to increase the size of the code? (Pharize may not respect this since the code may be compressed).

Vincent, Pharize will (most probably always) increase the file size even with \ compression in comparison to a Library, because PHP_Archive_Creator bundles \ PHP_Archive into the PHAR to create and AFAIK does not remove any code documentation \ etc.! The main idea with the decorator Pharize is to create a (possibly compressed) \ PHAR with <Pack>ed <Script>s. The combination of both techniques is the key to \ success. Thus Pharize "decorates" a <Type> object. Reducing code size will not make any real difference - PHP_Archive is 12k, and should be used to bundle large applications (single file, small applications simply don't need to be pharred).

What you lose when you start cutting line endings, renaming variables and other optimizations of size is very important: you lose the ability to easily debug the application. Instead of "Notice on line 293, use of undeclared variable $longname" you will get "Notice on line 1, use of undeclared variable $v12" For normal files, this is probably not a big deal (but is still annoying) as you can open the file in a text browser. For pharred files, this is impossible. Most bugs are reported by end users, because developers tend to fix anything they find in testing. For this reason, it is extra crucial that it be easy to find the location of problems. Unless ScriptReorganizer can provide a simple and easy way to translate an error message to match the original file (and I can't think of any way - simple or complex), it will instead make maintenance extremely difficult. Some bugs can only be reproduced on a client machine until you know what caused them. I'm not saying that there is anything wrong with using ScriptReorganizer, but I do think it would be a *very* good idea to mention this drawback in the documentation, so that people can make the intelligent choice and run ScriptReorganizer prior to and separate from pharring. This will give the immediate benefit that you can test the files outside the phar when attempting to reproduce a bug, and will be able to quickly cross-reference bugs reported by endusers. Greg