Fwd: [PEPr] Comment on HTML::PHPTAL

Forwarding to pear-dev@... ---------- Forwarded message ---------- From: Kornel Lesiński <kornel@aardvarkmedia.co.uk> Date: 2009/4/19 Subject: Re: [PEPr] Comment on HTML::PHPTAL To: "\"Till Klampaeckel\"" <till@php.net> On 19.04.2009, at 19:18, Till Klampaeckel wrote: >> This is in older/stable version for backwards compatibility. All global >> constants except PHPTAL_DIR are removed in upcoming version. > > Maybe wrap it into a phing task and remove the constants for the release > on PEAR. I don't think there's a requirement to keep BC with non-PEAR > versions, I could be wrong though. Since this will be your first release on > PEAR you get a clean start. I don't mind breaking small things when migrating to PEAR. However PHPTAL is an old project and I've got existing users. I don't want to fracture userbase, so a completely clean start is not an option for me. >> Some suggestions, like prefixing private variables, seem to be for PHP4. >> Am I really supposed to "fix" all of those? > > The idea is to follow the CS 100%. We frequently have this discussion and > while it's annoying at first, it helps a lot of people in the long run. > E.g. the benefits are that developers who are familiar with PEAR code, will > have it easier to work with your code as well. Or maybe down the road > someone else takes over maintainership of your package, etc. p.p.. Sure, I generally agree and I've already added plenty of doc comments, cleaned up formatting, etc. However I don't believe that 100% of reported issues make code easier to read or maintain. I have few cases where I think blind adherence would be counter-productive. Can my package be rejected because of lack of space after comma? If not, how can I tell which issues absolutely have to be fixed now, which can be fixed later, which can be ignored? -- regards, Kornel