Re: Re : [PEAR-DEV] proposal rewrite : PHP_Debug

Loic, Loïc Vernet wrote: > Hi Philippe, > > - Thanks for you comments. Yes your are right, i need to switch my proposal > to proposed status but before i need to rewrite the proposal page witch > corresponds to the old proposal. I'll do it soon. > > - The correct full email is here, all my important questions of point 3) were missing. > > http://marc.theaimsgroup.com/?l=pear-dev&m=114846643607638&w=2 > > > - Yes the design error concerning the global object is fixed, there is no more useless global > object > > - I don't know the Event_Dispatcher and XDebug classes, i'll take a look to see what > is possible to integrate/improve in my package. > > - The popup is planned, it will just be a new renderer. > > - I'd also like also to have news of Andreas because in fact my new proposal is simply a > rewrite of both our proposals. > > > Thanks !! Loïc. > > 3) I'd need some clarifications on some points : > a) The category of the package is PHP, the main classe name is Debug > So my constants concerning Debug are prefixed with "PHP_DEBUG_" > I have a subclass Debug_Line so the constant concerning this one > should be \ > PHP_DEBUG_LINE , right ? (i have to correct it) Correct. > b) Can i use i a package (Pear::SQL_Parser) that is in devel status ? Yes. However, you'll need to supervise the status of the package with any BC breaks, that may impact your PHP_Debug package. > c) I'd like to give the choice to my users to use Pear or not, so > should i maintain 2 packages, one on Pear that will be 100% pear and > one other on Sourceforge for the non pear version ? Or should i code > this properly directly in the package ? If this is possible what is > the best way to do that ? It's up to you, if you have enough resource to maintain 2 such versions. However, it would also probably be confusing in userland if APIs diverge. As a PEAR user, I'd say just stick with the PEAR version :-) But, in any case, do not add switches in the code to know which version is being used. It all depends on how and where your dependence on PEAR packages is. > d) In this new version i use an option array, is there a naming > convention for the index ? What i have done is that i prefix the index > with the class name where it will be used, example : > > protected $defaultOptions = array( > 'DEBUG_render_mode' => 'HTML_Table', // Render mode > 'DEBUG_restrict_access' => true ) There is no standard, besides being consistent throughout your package (i.e. always use underscores "render_mode", or always use studlyCaps "renderMode" for the indexes in your option array) For your given example, I'd drop the "DEBUG_" prefix altogether. >Does that make sense ? Or should i prefix it with the compete name ? > PHP_DEBUG ? Or nothing ? No. No need ot the package name in it. > e) For my renderer HTML_Table, i have stored all the html code in a > separate config file named HTML_Table_Config, with a simple object > with static properties, is this correct way of coding ? The goal is to > keep the main class HTML_Table the cleaner possible. I haven't looked enough in details into your code to answer that one, but the name of that class seems wrong. Maybe PHP_Debug_Renderer_HTML_Table? > Thanks for your feedback and for reading this email until this end. -Philippe