Questions of code standards

[Kristopher Ives-2]

I wish to propose a package I developed called Services_Shipping (I hope)
that provides a unified driver-based abstract shipping API, similar to how
MDB2 provides portable database package and Payment_Process provides
driver-based transactions.

I code in a different way than PEAR's coding style standards, mainly I use
tabs and don't like spaces between my opening brackets. I use Eclipse
currently and will likely create an Eclipse formatting profile for
formatting to PEAR standard.

1.) Anyone currently code using tabs and have an Eclipse or bash script
(using some whitepsace program) that formats to PEAR standards?

2.) My PEAR package has 80+ source files, is this a problem? I am not
interested in combining source files into larger ones.

3.) Should I include my 2 driver packages (UPS and DHL) in my original
proposal for Services_Shipping (these would be Services_Shipping_UPS and
Services_Shipping_DHL, correct?)

4.) Should I generate documentation (phpDocumentor) and include the
documentation or only submit my code and PEAR will generate the doc?

5.) After proposal will I get a reason why my package isn't accepted so I
may fix the issues and re-submit? Is there a limit on how quick I may
re-submit my proposal?

Peace My PHP Ganstas,
Kristopher Ives

[designatevoid]

Greetings,

I can answer questions 4 & 5 and suggest on 1.

On Thu, Jul 17, 2008 at 6:35 PM, Kristopher Ives <kristopher.ives@...>
wrote:

> I wish to propose a package I developed called Services_Shipping (I hope)
> that provides a unified driver-based abstract shipping API, similar to how
> MDB2 provides portable database package and Payment_Process provides
> driver-based transactions.
>
> I code in a different way than PEAR's coding style standards, mainly I use
> tabs and don't like spaces between my opening brackets. I use Eclipse
> currently and will likely create an Eclipse formatting profile for
> formatting to PEAR standard.
>
> 1.) Anyone currently code using tabs and have an Eclipse or bash script
> (using some whitepsace program) that formats to PEAR standards?

I know you can double check that an operation worked with the
PHP_CodeSniffer package.

2.) My PEAR package has 80+ source files, is this a problem? I am not
> interested in combining source files into larger ones.


As long as it's a good design given the complexity of the problem domain it
should be fine.


> 3.) Should I include my 2 driver packages (UPS and DHL) in my original
> proposal for Services_Shipping (these would be Services_Shipping_UPS and
> Services_Shipping_DHL, correct?)
>
> 4.) Should I generate documentation (phpDocumentor) and include the
> documentation or only submit my code and PEAR will generate the doc?
>

In your package description there is a place for a link to the
documentation.  Generate the documentation and put it onto a web server and
link it.


> 5.) After proposal will I get a reason why my package isn't accepted so I
> may fix the issues and re-submit? Is there a limit on how quick I may
> re-submit my proposal?


During the voting process you can see comments and reasons for the
individual developer's vote.

When I did it there was no way to actually re-submit.  I had to post to this
list to get my old (rejected) package renamed so I could create a new
package with all of the same info in it but at the beginning of the process.

I started my project (Log_XML) in October 2006 and haven't had any
problems.  I'm not sure if / when the rejected packages' data gets deleted
from the pear database though.

I hope this helped,

Michael Gower

[Joe Stump]

On Jul 17, 2008, at 6:35 PM, Kristopher Ives wrote:

> I code in a different way than PEAR's coding style standards, mainly  
> I use
> tabs and don't like spaces between my opening brackets.

I too used to code a different way. Then I realized that I was  
committing a bunch of code to PEAR and got lazy so I just followed the  
herd. I figure the PEAR coding standards are more heavily vetted by  
people smarter than me. Also, as I said before, I'm lazy. We follow  
these same standards at Digg with a few slight modifications for  
template code.

> 1.) Anyone currently code using tabs and have an Eclipse or bash  
> script
> (using some whitepsace program) that formats to PEAR standards?

You can open files in vim and type "retab" to change tabs to spaces I  
think. Otherwise, off the hip, sed s/\t/    /g could very well do it.

> 2.) My PEAR package has 80+ source files, is this a problem? I am not
> interested in combining source files into larger ones.

PEAR doesn't have any limit on the number of files a package may  
contain that I'm aware of. The general rule of thumb is one file per  
class, though I've seen this broken in a few places. The one thing you  
may want to consider is breaking your UPS and DHL drivers into sub-
packages that can be optionally installed (See MDB2 and Validate for  
examples of subpackages).

> 3.) Should I include my 2 driver packages (UPS and DHL) in my original
> proposal for Services_Shipping (these would be Services_Shipping_UPS  
> and
> Services_Shipping_DHL, correct?)

Yes. Propose the whole thing and we'll worry about breaking things up  
into sub-packages once the whole thing has been approved. Unless  
someone chimes in and says that's wrong, which is entirely possibly  
since I'm often wrong. :)

> 4.) Should I generate documentation (phpDocumentor) and include the
> documentation or only submit my code and PEAR will generate the doc?

Documentation isn't created for proposals. Once your package is  
created and released PEAR handles the creation of the phpDocumentor  
documentation. The management of DocBook documentation is handled  
outside of your package (though you're free to include the DocBook  
sources inside of your package - see role="doc").

> 5.) After proposal will I get a reason why my package isn't accepted  
> so I
> may fix the issues and re-submit? Is there a limit on how quick I may
> re-submit my proposal?

It's very rare for a package to be patently voted down. There are  
three phases to the proposal process: draft, proposal, voting.  
Normally all of the issues regarding style, performance, viability,  
etc. are addressed during the draft and proposal stages, which have no  
time constraints. What I normally do is leave my packages in a  
proposal state until I've been able to address all of the concerns  
raised by the community (whether that's fixing the code or simply  
rebutting their concerns).

Hope that all helps. Let us know if you have further questions. Also,  
thanks!

--Joe

--
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Kristopher Ives-2]

Thanks for the help. Before I continue I want to ensure my messages are
properly being sent to the mailing list (specificly in reply). I use GMail
and use the Reply To All option which replies to the message I click and CCs
to the mailing list, is this legit?

I use the PHP DOMXML class/functions (which are included by default), but I
think PEAR has some XML classes too. I don't really want to rewrite
everything, and the DOMXML and DOMXPath stuff works really well so far.

I am making my proposal tonight, do you think this XML class will be an
issue?

On Thu, Jul 17, 2008 at 9:11 PM, Joe Stump <joe@...> wrote:

>
> On Jul 17, 2008, at 6:35 PM, Kristopher Ives wrote:
>
>  I code in a different way than PEAR's coding style standards, mainly I use
>> tabs and don't like spaces between my opening brackets.
>>
>
> I too used to code a different way. Then I realized that I was committing a
> bunch of code to PEAR and got lazy so I just followed the herd. I figure the
> PEAR coding standards are more heavily vetted by people smarter than me.
> Also, as I said before, I'm lazy. We follow these same standards at Digg
> with a few slight modifications for template code.
>
>  1.) Anyone currently code using tabs and have an Eclipse or bash script
>> (using some whitepsace program) that formats to PEAR standards?
>>
>
> You can open files in vim and type "retab" to change tabs to spaces I
> think. Otherwise, off the hip, sed s/\t/    /g could very well do it.
>
>  2.) My PEAR package has 80+ source files, is this a problem? I am not
>> interested in combining source files into larger ones.
>>
>
> PEAR doesn't have any limit on the number of files a package may contain
> that I'm aware of. The general rule of thumb is one file per class, though
> I've seen this broken in a few places. The one thing you may want to
> consider is breaking your UPS and DHL drivers into sub-packages that can be
> optionally installed (See MDB2 and Validate for examples of subpackages).
>
>  3.) Should I include my 2 driver packages (UPS and DHL) in my original
>> proposal for Services_Shipping (these would be Services_Shipping_UPS and
>> Services_Shipping_DHL, correct?)
>>
>
> Yes. Propose the whole thing and we'll worry about breaking things up into
> sub-packages once the whole thing has been approved. Unless someone chimes
> in and says that's wrong, which is entirely possibly since I'm often wrong.
> :)
>
>  4.) Should I generate documentation (phpDocumentor) and include the
>> documentation or only submit my code and PEAR will generate the doc?
>>
>
> Documentation isn't created for proposals. Once your package is created and
> released PEAR handles the creation of the phpDocumentor documentation. The
> management of DocBook documentation is handled outside of your package
> (though you're free to include the DocBook sources inside of your package -
> see role="doc").
>
>  5.) After proposal will I get a reason why my package isn't accepted so I
>> may fix the issues and re-submit? Is there a limit on how quick I may
>> re-submit my proposal?
>>
>
> It's very rare for a package to be patently voted down. There are three
> phases to the proposal process: draft, proposal, voting. Normally all of the
> issues regarding style, performance, viability, etc. are addressed during
> the draft and proposal stages, which have no time constraints. What I
> normally do is leave my packages in a proposal state until I've been able to
> address all of the concerns raised by the community (whether that's fixing
> the code or simply rebutting their concerns).
>
> Hope that all helps. Let us know if you have further questions. Also,
> thanks!
>
> --Joe
>

[Joe Stump]

On Jul 17, 2008, at 9:51 PM, Kristopher Ives wrote:

> Thanks for the help. Before I continue I want to ensure my messages  
> are
> properly being sent to the mailing list (specificly in reply). I use  
> GMail
> and use the Reply To All option which replies to the message I click  
> and CCs
> to the mailing list, is this legit?

That's fine I think. It just means the sender gets a double copy, but  
that doesn't bother me so much.

> I use the PHP DOMXML class/functions (which are included by  
> default), but I
> think PEAR has some XML classes too. I don't really want to rewrite
> everything, and the DOMXML and DOMXPath stuff works really well so  
> far.
>
> I am making my proposal tonight, do you think this XML class will be  
> an
> issue?

Nope. You can depend on PHP classes and functions (it's normally  
encouraged depending on the cases). Most of the XML parsing classes in  
PEAR are (IMO) largely deprecated with the introduction of SimpleXML  
and the DOM stuff. With PEAR's package.xml files you can set  
dependencies on extensions, which you should definitely do (in case  
someone compiled it WITHOUT those classes enabled).

--Joe

--
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Baptiste Autin]

>1.) Anyone currently code using tabs and have an Eclipse or bash script
>(using some whitepsace program) that formats to PEAR standards?

In Eclipse (that I use too), you can choose your tab policy per project (by
spaces or by tabs, and how many spaces a tab). My PEAR project is configured
with spaces. All my other projects with tabs.

2.) My PEAR package has 80+ source files, is this a problem? I am not
interested in combining source files into larger ones.

spl_autoload must certainly be your friend !


Baptiste


--
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php