FAQ

Or
a) am I missing something
b) is it the core developers' opinion that core classes have
the right of way?
<kidding>
If things behave like that at least there should be a list of "reserved
class names" just like with other keywords. And of course that list must
not be changed as it is considered practical.
</kidding>

I don't think PEAR has done anything wrong here; it was never disallowed
to have a class named Date. And it's not only a PEAR problem but affects
pretty much everyone out there with more than a few hundred lines of OO
code. If it was a failure of QA, clearly one of the "language core" QA
itself.

Maybe namespaces are a solution, but until there is a good solution for
the basic problem, stop adding classes to the core that way. Often it's
hard enough to find short yet precise class names; and there is also a
set of commonly used or agreed-on class names (just think of the common
patterns). In no case anything done in the core must inflict with or
otherwise touch that set - or forget about that "enterprise ready" stuff
altogether.

-mp.

Search Discussions

  • Matthias Pigulla at Nov 25, 2005 at 11:23 am

    obviously one problem is that PEAR does ignore coding standards.
    Classes should be prefixed in both pear and core. And
    neither Date nor
    File is in any way prefixed.
    Err, how are we supposed to prefix PEAR::Date?

    PEAR_Date?
    Date_Date?
    Lala_Date?
    The whole thing is nothing PEAR is to blame for. Even if PEAR had
    noticed it earlier and renamed it to supercalifragilistic_Date and had
    gotten out the update to everyone fast enough - still it would require
    everyone using the PEAR class to reflect the change in their very own
    codebases.

    -mp.
  • Matthias Pigulla at Nov 26, 2005 at 11:24 pm
    I have to back Sebastian with what he said. Obviously the release methodology currently applied does NOT work, neither for the project nor the community around it.

    Do it how ever you like - discuss whether it's legal to add new features on HEAD only or on release branches like Jani said.

    BUT: Once you agree the work is done on a branch and you make something available that has a RC in it's version name, it's GAME OVER. No more features. Only bugfixes.

    That is the only way for ppl to make sure there will be no unnecessary and unexpected changes anymore. Once my software passes tests with an RC, I can assume in good faith that it's very unlikely to break again.

    You cannot expect folks to re-test everything with every new RC, and so it's not PEAR's fault if they were not the first to notice the problems.

    Remember the discussion about curlies? I also never understood why that had to be tackled in an RC5.

    Should you find out late in this process a feature has been forgotten (i.e. #ifdef'd out) and you all agree that it has to go in - abort the RC phase, put it in again, restart (maybe with another RC name) to make ppl clear that they *do* need to re-test.

    If you're kind, assert that there will be a certain time between RCs and releases, or communicate with your major community projects out there to make sure they do their work or do whatever.

    But there is just a single simple basic rule that needs to be adhered to - that's all Sebastian pointed out.

    -mp.

    -----Ursprüngliche Nachricht-----
    Von: Ilia Alshanetsky
    Gesendet: Samstag, 26. November 2005 16:49
    An: Sebastian Bergmann
    Cc: internals@lists.php.net
    Betreff: Re: [PHP-DEV] Re: PHP 5.1 (Or How to break tousands
    of apps out there)


    No one project follows the same release methodoly, everyone
    uses what works for them and the community around the project.

    Ilia

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Ilia Alshanetsky at Nov 27, 2005 at 5:23 am

    Matthias Pigulla wrote:
    I have to back Sebastian with what he said. Obviously the release methodology currently applied does NOT work, neither for the project nor the community around it.
    It has worked for many years, just because of one problem you don't
    scrap the process.
    BUT: Once you agree the work is done on a branch and you make something available that has a RC in it's version name, it's GAME OVER. No more features. Only bugfixes.
    RCs are there for testing, if you don't test them don't complain when
    things break. The main reason for RCs is to spot critical bugs and
    important regressions. Some of those are test suit can pickup, but most
    issues are discovered through "real" usage.
    You cannot expect folks to re-test everything with every new RC, and so it's not PEAR's fault if they were not the first to notice the problems.
    That is exactly what's expected.
    Remember the discussion about curlies? I also never understood why that had to be tackled in an RC5.
    They were removed.

    Ilia
  • Mbneto at Nov 27, 2005 at 1:35 pm
    Ilia,

    I do not agree with this. Since there should be only bugfixes in RC
    I should only test to see if the known problems are gone and there are
    no regressions. Check if the NEW classe/function clashes with mine's
    or PEAR's not!


    You cannot expect folks to re-test everything with every new RC, and so it's not PEAR's fault if they were not the first to notice the problems.
    That is exactly what's expected.
  • Ilia Alshanetsky at Nov 27, 2005 at 1:55 pm

    mbneto wrote:
    Ilia,

    I do not agree with this. Since there should be only bugfixes in RC
    I should only test to see if the known problems are gone and there are
    no regressions. Check if the NEW classe/function clashes with mine's
    or PEAR's not!
    Some bug fixes may cause regressions in behavior, which is why every RC
    needs to be tested.

    Ilia

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedNov 25, '05 at 10:47a
activeNov 27, '05 at 1:55p
posts6
users3
websitephp.net

People

Translate

site design / logo © 2022 Grokbase