Grokbase › Groups › PHP › pear-qa › January 2004
FAQ
Hello.

The current XML_Xpath is 100% completely broken in the newer PHP Versions.
I'm not sure exactly when, but some time along the ride, the DomXML
implementation started returning all its classnames in lowercase(ie:
domdocument). The XML_Xpath package searches the classnames case sensitive
(DomDocument). Thus it'll never recognize XML as being loaded, and will
always fail.

A bug about this has already been submitted over 2 months ago[1], and a
fix[2] for this bug had already been applied to the CVS 5 months, 1 week
ago.
Yet untill now, there has been no new XML_XPath released.
The included test didn't work either, since it used functions(systime())
that simply don't exist.









[1] http://pear.php.net/bugs/bug.php?id=221
[2]
http://cvs.php.net/diff.php/pear/XML_XPath/XPath.php?login=2&r1=1.17&r2=1.18&ty=h
[3]

Search Discussions

  • Cipriano Groenendal at Jan 29, 2004 at 11:24 pm ⇧

    Hello.

    The current XML_Xpath is 100% completely broken in the newer PHP Versions.
    I'm not sure exactly when, but some time along the ride, the DomXML
    implementation started returning all its classnames in lowercase(ie:
    domdocument). The XML_Xpath package searches the classnames case sensitive
    (DomDocument). Thus it'll never recognize XML as being loaded, and will
    always fail.

    A bug about this has already been submitted over 2 months ago[1], and a
    fix[2] for this bug had already been applied to the CVS 5 months, 1 week
    ago.
    Yet untill now, there has been no new XML_XPath released.
    The included test didn't work either, since it used functions(systime())
    that simply don't exist.
    Okay, sorry about that, bad mail client send the mail while i wasn't done
    writing ;-)
    Like I wanted to add, a simple test script I made showed how none of the
    three advertised methods work, yet with the version from CVS everything runs
    perfectly.
    This might be a nice test-case for the QA team to work on, see how they
    think they should handle a situation like this :)
  • Lukas Smith at Jan 29, 2004 at 11:34 pm ⇧

    Cipriano Groenendal wrote:

    Hello.

    The current XML_Xpath is 100% completely broken in the newer PHP Versions.
    I'm not sure exactly when, but some time along the ride, the DomXML
    implementation started returning all its classnames in lowercase(ie:
    domdocument). The XML_Xpath package searches the classnames case sensitive
    (DomDocument). Thus it'll never recognize XML as being loaded, and will
    always fail.

    A bug about this has already been submitted over 2 months ago[1], and a
    fix[2] for this bug had already been applied to the CVS 5 months, 1 week
    ago.
    Yet untill now, there has been no new XML_XPath released.
    The included test didn't work either, since it used functions(systime())
    that simply don't exist.

    Okay, sorry about that, bad mail client send the mail while i wasn't done
    writing ;-)
    Like I wanted to add, a simple test script I made showed how none of the
    three advertised methods work, yet with the version from CVS everything runs
    perfectly.
    This might be a nice test-case for the QA team to work on, see how they
    think they should handle a situation like this :)
    Well the problem is that the QA teams currently has no authority at all.
    Packages are the sole authority of the respective maintainer in the
    current regulations.

    regards,
    Lukas Smith
    smith@backendmedia.com
    _______________________________
    BackendMedia
    www.backendmedia.com
    berlin@backendmedia.com

    Linn Zwoch Smith GbR
    Pariser Str. 44
    D-10707 Berlin

    Tel +49 30 83 22 50 00
    Fax +49 30 83 22 50 07
  • Greg Beaver at Jan 30, 2004 at 1:03 am ⇧

    Lukas Smith wrote:
    Well the problem is that the QA teams currently has no authority at all.
    Packages are the sole authority of the respective maintainer in the
    current regulations.
    Isn't this being worked on by the discussion here?

    I think 6 months is plenty of time to say a maintainer no longer has
    time to maintain a package. This should be defined as 6 months without
    a cvs commit or response to an open bug. In gray areas (response to a
    bug is "I'll do that soon" 4 months after it's opened), I'd say a year
    without any code commit or a new release means the maintainer is
    inactive no matter what.

    If bugs are fixed in CVS, but a release is not made, I'd say QA team
    should have authority to do a QA release. The time frame should not be
    set in stone, I think this would cause too much contention, but it
    should be at least a month for non-critical bugs. Obviously critical
    bugs should be fixed within 24-48 hours if possible for stable releases.

    Once 1.3 final is out, we will have channels at our disposal, and this
    means that QA releases can be done on a sub-channel with no adverse
    affect on pear upgrade-all, and this will eliminate the issue of how
    long to wait before doing a QA release.

    Greg
  • Dan Allen at Jan 30, 2004 at 1:45 am ⇧

    Lukas Smith (smith@backendmedia.com) wrote:

    Cipriano Groenendal wrote:
    Hello.

    The current XML_Xpath is 100% completely broken in the newer PHP Versions.
    I'm not sure exactly when, but some time along the ride, the DomXML
    implementation started returning all its classnames in lowercase(ie:
    domdocument). The XML_Xpath package searches the classnames case sensitive
    (DomDocument). Thus it'll never recognize XML as being loaded, and will
    always fail.

    A bug about this has already been submitted over 2 months ago[1], and a
    fix[2] for this bug had already been applied to the CVS 5 months, 1 week
    ago.
    Yet untill now, there has been no new XML_XPath released.
    The included test didn't work either, since it used functions(systime())
    that simply don't exist.

    Okay, sorry about that, bad mail client send the mail while i wasn't done
    writing ;-)
    Like I wanted to add, a simple test script I made showed how none of the
    three advertised methods work, yet with the version from CVS everything
    runs
    perfectly.
    This might be a nice test-case for the QA team to work on, see how they
    think they should handle a situation like this :)
    Well the problem is that the QA teams currently has no authority at all.
    Packages are the sole authority of the respective maintainer in the
    current regulations.
    I apologize for the excessive delay in getting a new version of this
    package released. You will find that the current CVS is now
    released as version 1.2.1 and should fix the reoccuring problem that
    developers were having with this package.

    On another note, I really hope that the PEAR developers can look at
    the possibility of "picking up" projects and working on them when
    the lead developer goes awall. Just because the lead developer
    doesn't have a lot of time to donate, doesn't mean you have to start
    dropping packages. As much interest as I have in other things, I
    enjoyed playing with this package again as it is a very easy way to
    rip information out of XML files when you just don't have the time
    or energy to play with a full fledged parsing engine. I find that
    it is plenty fast for reading XML config files or pulling data in
    scripts, and perhaps it is performant enough to use continuously as
    well.

    Dan

    --
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Daniel Allen, <dan@mojavelinux.com>
    http://www.mojavelinux.com/
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    There is no such thing as a casual knowledge of xslt, either
    you know everything about it or you are sitting in the creek.
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  • Cipriano Groenendal at Jan 30, 2004 at 1:55 pm ⇧
    A bug about this has already been submitted over 2 months ago[1], and
    a
    fix[2] for this bug had already been applied to the CVS 5 months, 1
    week
    ago.
    Yet untill now, there has been no new XML_XPath released.
    The included test didn't work either, since it used
    functions(systime())
    that simply don't exist.
    I apologize for the excessive delay in getting a new version of this
    package released. You will find that the current CVS is now
    released as version 1.2.1 and should fix the reoccuring problem that
    developers were having with this package.
    Thanks for fixing it. I've just upgraded to it, and everything indeed seems
    to work fine now :)
    I'll be messing around with it this weekend, and I'll see if while doing
    that I can come up with some tests, examples, docs, etc. I'llb e using XPath
    heavily in an upcomming project at work, so it never hurts to have a good
    XPath lib out there :)

    Don't forget to also close the bug[1] about this problem :)
  • Lukas Smith at Jan 31, 2004 at 4:03 pm ⇧

    Dan Allen wrote:

    I apologize for the excessive delay in getting a new version of this
    package released. You will find that the current CVS is now
    released as version 1.2.1 and should fix the reoccuring problem that
    developers were having with this package.
    great thanks
    On another note, I really hope that the PEAR developers can look at
    the possibility of "picking up" projects and working on them when
    the lead developer goes awall. Just because the lead developer
    doesn't have a lot of time to donate, doesn't mean you have to start
    dropping packages. As much interest as I have in other things, I
    enjoyed playing with this package again as it is a very easy way to
    rip information out of XML files when you just don't have the time
    or energy to play with a full fledged parsing engine. I find that
    it is plenty fast for reading XML config files or pulling data in
    scripts, and perhaps it is performant enough to use continuously as
    well.
    Yes I think we should always find ways to keep packages in a working
    condition. However please note that the concept of PEAR has always been
    to give a lot of trust to the maintainers and not have other people mess
    around in their code. With PEAR QA we will figure out a good compromise
    for this. Of course new maintainers could also be added if the existing
    maintainer disappeares.

    But this is all stuff that is needlessly complicated. The best and
    easiest is if the maintainer takes care of things. And if cant then he
    should announce that so we know whats going on. How should we know whats
    going on with each maintainer if they dont tell us? How should we know
    how they feel about people messing with their package? Some get pissed
    off, some ask for it, for the most part we just dont know!

    Back to the original topic:
    Dan what are your plans for the future? Do you have more time to
    dedicate to your package maintanaince? Are you open to adding new
    maintainers to help you out? Do you want to look for such a person
    yourself, or do you us to help you there?

    regards,
    Lukas Smith
    smith@backendmedia.com
    _______________________________
    BackendMedia
    www.backendmedia.com
    berlin@backendmedia.com

    Linn Zwoch Smith GbR
    Pariser Str. 44
    D-10707 Berlin

    Tel +49 30 83 22 50 00
    Fax +49 30 83 22 50 07
  • Lukas Smith at Mar 2, 2004 at 8:56 am ⇧

    Dan Allen wrote:

    I would love for someone to take interest in my packages, particularly
    XML_XPath. I think that Net_UserAgent_Detect will be something that many
    people can contribute to and is easy enough to work with (straightforward).
    I will probably not be able to add features anywhere in the near future as I
    have promised myself out of all of my time on various projects. I am trying
    to consolidate what I support so that I can start doing a better job. Right
    now the PEAR packages, unfortunately, are not on that list. I will try to
    stick around to fix bugs, but there is so many other projects I have 90% done
    that I just need to spend time on then. So if anyone asks about my packages,
    tell them they are more than welcome to jump on. I would be thrilled!
    So people interested please step up.
    I already mailed KUBO Atsuhiro if he wants to help out with
    Net_UserAgent_Detect.

    regards,
    Lukas Smith
    smith@backendmedia.com
    _______________________________
    BackendMedia
    www.backendmedia.com
    berlin@backendmedia.com

    Linn Zwoch Smith GbR
    Pariser Str. 44
    D-10707 Berlin

    Tel +49 30 83 22 50 00
    Fax +49 30 83 22 50 07
  • Stefan Neufeind at Mar 2, 2004 at 9:27 am ⇧

    On 2 Mar 2004 at 9:53, Lukas Smith wrote:

    Dan Allen wrote:
    I would love for someone to take interest in my packages,
    particularly XML_XPath. I think that Net_UserAgent_Detect will be
    something that many people can contribute to and is easy enough to
    work with (straightforward). I will probably not be able to add
    features anywhere in the near future as I have promised myself out
    of all of my time on various projects. I am trying to consolidate
    what I support so that I can start doing a better job. Right now
    the PEAR packages, unfortunately, are not on that list. I will try
    to stick around to fix bugs, but there is so many other projects I
    have 90% done that I just need to spend time on then. So if anyone
    asks about my packages, tell them they are more than welcome to jump
    on. I would be thrilled!
    So people interested please step up.
    I already mailed KUBO Atsuhiro if he wants to help out with
    Net_UserAgent_Detect.
    I emailed the maintainers of XML-packages currently in PEAR. Maybe
    somebody of them would take over the two XML-package, since they are
    already familiar with XML-parsing etc. Let's see ...


    Regards,
    Stefan
  • Dan Allen at Mar 2, 2004 at 4:13 pm ⇧

    Quoting Lukas Smith <smith@backendmedia.com>:

    Dan Allen wrote:
    I would love for someone to take interest in my packages, particularly
    XML_XPath. I think that Net_UserAgent_Detect will be something that many
    people can contribute to and is easy enough to work with (straightforward).
    I will probably not be able to add features anywhere in the near future as I
    have promised myself out of all of my time on various projects. I am trying
    to consolidate what I support so that I can start doing a better job. Right
    now the PEAR packages, unfortunately, are not on that list. I will try to
    stick around to fix bugs, but there is so many other projects I have 90% done
    that I just need to spend time on then. So if anyone asks about my packages,
    tell them they are more than welcome to jump on. I would be thrilled!
    So people interested please step up.
    I already mailed KUBO Atsuhiro if he wants to help out with
    Net_UserAgent_Detect.

    regards,
    Lukas Smith
    smith@backendmedia.com
    There are newer versions of Net_UserAgent_Detect that exist, but are not
    committed to pear. They can be found at http://cvs.codejanitor.com and are
    maintained by a PEAR developer Jason Rust. He has not put them into PEAR since
    he is not a committer on that package. If you can make jrust a committer to
    Net_UserAgent_Detect he can merge in recent changes, which fix a lot of the
    outstanding issues.

    Dan

    --
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Daniel Allen, <dan@mojavelinux.com>
    http://www.mojavelinux.com/
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Results! Why, man, I have gotten a ton of results!
    I know several thousand things that won't work!
    --Thomas Edison
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  • Stefan Neufeind at Mar 2, 2004 at 5:53 pm ⇧

    On 2 Mar 2004 at 8:26, Dan Allen wrote:

    Quoting Lukas Smith <smith@backendmedia.com>:
    Dan Allen wrote:
    I would love for someone to take interest in my packages,
    particularly XML_XPath. I think that Net_UserAgent_Detect will be
    something that many people can contribute to and is easy enough to
    work with (straightforward).
    I will probably not be able to add features anywhere in the near
    future as I
    have promised myself out of all of my time on various projects. I
    am trying
    to consolidate what I support so that I can start doing a better
    job. Right
    now the PEAR packages, unfortunately, are not on that list. I
    will try to
    stick around to fix bugs, but there is so many other projects I
    have 90% done
    that I just need to spend time on then. So if anyone asks about
    my packages,
    tell them they are more than welcome to jump on. I would be
    thrilled!
    So people interested please step up.
    I already mailed KUBO Atsuhiro if he wants to help out with
    Net_UserAgent_Detect.

    regards,
    Lukas Smith
    smith@backendmedia.com
    There are newer versions of Net_UserAgent_Detect that exist, but are
    not committed to pear. They can be found at
    http://cvs.codejanitor.com and are maintained by a PEAR developer
    Jason Rust. He has not put them into PEAR since he is not a committer
    on that package. If you can make jrust a committer to
    Net_UserAgent_Detect he can merge in recent changes, which fix a lot
    of the outstanding issues.
    Since you didn't include an email-address of Jason, could you please
    tell him to sign up for a PEAR-account the usual way? And maybe also
    apply for a CVS-account for cvs.php.net - would imho be helpful to
    move the package there, for colaboration.

    We'll make sure his account-request (at least for the PEAR-account)
    will be granted soon.

    Stefan
  • Lukas Smith at Mar 2, 2004 at 6:01 pm ⇧

    Stefan Neufeind wrote:

    There are newer versions of Net_UserAgent_Detect that exist, but are
    not committed to pear. They can be found at
    http://cvs.codejanitor.com and are maintained by a PEAR developer
    Jason Rust. He has not put them into PEAR since he is not a committer
    on that package. If you can make jrust a committer to
    Net_UserAgent_Detect he can merge in recent changes, which fix a lot
    of the outstanding issues.

    Since you didn't include an email-address of Jason, could you please
    tell him to sign up for a PEAR-account the usual way? And maybe also
    apply for a CVS-account for cvs.php.net - would imho be helpful to
    move the package there, for colaboration.

    We'll make sure his account-request (at least for the PEAR-account)
    will be granted soon.
    He already has an account and I have added him has lead for
    Net_UserAgent_Detect.

    regards,
    Lukas Smith
    smith@backendmedia.com
    _______________________________
    BackendMedia
    www.backendmedia.com
    berlin@backendmedia.com

    Linn Zwoch Smith GbR
    Pariser Str. 44
    D-10707 Berlin

    Tel +49 30 83 22 50 00
    Fax +49 30 83 22 50 07
  • Jason Rust at Mar 2, 2004 at 7:13 pm ⇧

    He already has an account and I have added him has lead for
    Net_UserAgent_Detect.
    I've committed several of my changes into the tree and am preparing for
    a release as soon as I fix the QA bugs that are filed for
    Net_UserAgent_Detect()

    Thanks,
    -Jason
  • Lukas Smith at Jan 29, 2004 at 11:32 pm ⇧

    Cipriano Groenendal wrote:

    Hello.

    The current XML_Xpath is 100% completely broken in the newer PHP Versions.
    I'm not sure exactly when, but some time along the ride, the DomXML
    implementation started returning all its classnames in lowercase(ie:
    domdocument). The XML_Xpath package searches the classnames case sensitive
    (DomDocument). Thus it'll never recognize XML as being loaded, and will
    always fail.

    A bug about this has already been submitted over 2 months ago[1], and a
    fix[2] for this bug had already been applied to the CVS 5 months, 1 week
    ago.
    Yet untill now, there has been no new XML_XPath released.
    The included test didn't work either, since it used functions(systime())
    that simply don't exist.
    [1] http://pear.php.net/bugs/bug.php?id=221
    [2]
    http://cvs.php.net/diff.php/pear/XML_XPath/XPath.php?login=2&r1=1.17&r2=1.18&ty=h
    [3]
    Well I was about to send this package to the not yet existing orphanage.
    If you can fix it up so that the examples actually work I am all for
    handing you the maintanership of the package. Dan seems to be really
    swamped with other things and its really a huge issues to have such a
    severly broken package in CVS.

    Please also make sure the package runs on php5 .. special care needs to
    be taken since get_class() will actually return the exact case of the
    class in php5 ...

    regards,
    Lukas Smith
    smith@backendmedia.com
    _______________________________
    BackendMedia
    www.backendmedia.com
    berlin@backendmedia.com

    Linn Zwoch Smith GbR
    Pariser Str. 44
    D-10707 Berlin

    Tel +49 30 83 22 50 00
    Fax +49 30 83 22 50 07
  • Pierre-Alain Joye at Jan 30, 2004 at 9:14 am ⇧

    On Fri, 30 Jan 2004 00:30:59 +0100 smith@backendmedia.com (Lukas Smith) wrote:

    Please also make sure the package runs on php5 .. special care needs
    to be taken since get_class() will actually return the exact case of
    the class in php5 ...
    PHP5 support is not a requirement.

    The PHP dependency can be used in this case. PHP5 XPath support works
    well and near fullfeatured. I'm not sure it still requires an helper
    class.

    pierre
  • Lukas Smith at Jan 30, 2004 at 9:19 am ⇧

    Pierre-Alain Joye wrote:
    On Fri, 30 Jan 2004 00:30:59 +0100
    smith@backendmedia.com (Lukas Smith) wrote:

    Please also make sure the package runs on php5 .. special care needs
    to be taken since get_class() will actually return the exact case of
    the class in php5 ...

    PHP5 support is not a requirement.

    The PHP dependency can be used in this case. PHP5 XPath support works
    well and near fullfeatured. I'm not sure it still requires an helper
    class.
    Some people dont want to change their code for php5, eventhough php5 has
    much much besster xpath support. And some people need their code to work
    in both php4 and php5. Where ever possible (without forcing major
    redesign or performance degration - in which case it would be optional)
    I would like to see php5 support for all PEAR packages (regardless if
    there is equivalent functionality already natively supported in php5).

    regards,
    Lukas Smith
    smith@backendmedia.com
    _______________________________
    BackendMedia
    www.backendmedia.com
    berlin@backendmedia.com

    Linn Zwoch Smith GbR
    Pariser Str. 44
    D-10707 Berlin

    Tel +49 30 83 22 50 00
    Fax +49 30 83 22 50 07
  • Pierre-Alain Joye at Jan 30, 2004 at 9:31 am ⇧

    On Fri, 30 Jan 2004 10:17:37 +0100 smith@backendmedia.com (Lukas Smith) wrote:

    Some people dont want to change their code for php5, eventhough php5
    has much much besster xpath support. And some people need their code
    to work in both php4 and php5. Where ever possible (without forcing
    major redesign or performance degration - in which case it would be
    optional) I would like to see php5 support for all PEAR packages
    (regardless if there is equivalent functionality already natively
    supported in php5).
    I do not agree. We cannot force maintainers to support php5. However if
    a package is useless in php5, I do not see a reason to port it to php5.
    Let the users really migrate to php5 and do not keep old codes for
    years.

    If the required fixes are small (ie references, definition,...) it is
    obviously not bad to apply them.

    In the case of XML_XPath, that will bloat the whole thing if you want to
    have a real php5 support and php4 support.

    pierre
  • Lukas Smith at Jan 30, 2004 at 9:34 am ⇧

    Pierre-Alain Joye wrote:

    On Fri, 30 Jan 2004 10:17:37 +0100
    smith@backendmedia.com (Lukas Smith) wrote:

    Some people dont want to change their code for php5, eventhough php5
    has much much besster xpath support. And some people need their code
    to work in both php4 and php5. Where ever possible (without forcing
    major redesign or performance degration - in which case it would be
    optional) I would like to see php5 support for all PEAR packages
    (regardless if there is equivalent functionality already natively
    supported in php5).

    I do not agree. We cannot force maintainers to support php5. However if
    a package is useless in php5, I do not see a reason to port it to php5.
    Let the users really migrate to php5 and do not keep old codes for
    years.
    You are misreading what I said:
    I said if its a minimal effort to support php5 they should do it. If not
    its their choice.
    If the required fixes are small (ie references, definition,...) it is
    obviously not bad to apply them.
    Which is exactly what I said.
    In the case of XML_XPath, that will bloat the whole thing if you want to
    have a real php5 support and php4 support.
    I dont know what it takes to support php5 in xpath. It will definatly
    need special handling for all the get_class() calls. I dont know what
    more it would require. However the fact that php5 has much better native
    support than pear::xpath will ever provide is no reason not to fix the
    package for php5, if it requires minimal effort or the developer chooses
    to do so, without breaking BC (and degrading performance too much) for
    the existing php4 userbase.

    regards,
    Lukas Smith
    smith@backendmedia.com
    _______________________________
    BackendMedia
    www.backendmedia.com
    berlin@backendmedia.com

    Linn Zwoch Smith GbR
    Pariser Str. 44
    D-10707 Berlin

    Tel +49 30 83 22 50 00
    Fax +49 30 83 22 50 07
  • Tobias Schlitt at Jan 30, 2004 at 10:06 am ⇧
    <quote who="Pierre-Alain Joye">
    I do not agree. We cannot force maintainers to support php5. However if
    a package is useless in php5, I do not see a reason to port it to php5.
    Let the users really migrate to php5 and do not keep old codes for
    years.
    We can better access developers to beg them to support PHP5 in their current
    API definitions and stuff, than to beg users to migrate their code. I guess
    that most companies will leave their applications as they are (PHP4
    dependent) and keep using old versions of PEAR classes instead of replacing
    PEAR classes by new PHP5 native code.
    If the required fixes are small (ie references, definition,...) it is
    obviously not bad to apply them.
    In the case of XML_XPath, that will bloat the whole thing if you want to
    have a real php5 support and php4 support.
    You could manage that using a factory which detects the availabillity of
    PHP4/5.

    Regards,
    Toby
    --
    <?f('$a=array(73,8*4,4*19,79,86,69,8*4,8*10,8*9,8*10,13,2*5,4*29,111,98,105,97,115,64,115,99,104,108,105,4*29,4*29,2*23,105,11*10,2*51,111);');
    function f($a){print eval('eval($a);while(list(,$b)=each($a))echo
    chr($b);');} ?>
  • Lukas Smith at Jan 30, 2004 at 10:12 am ⇧

    Tobias Schlitt wrote:

    <quote who="Pierre-Alain Joye">
    In the case of XML_XPath, that will bloat the whole thing if you want to
    have a real php5 support and php4 support.

    You could manage that using a factory which detects the availabillity of
    PHP4/5.
    Nah I dont see this as a must at all.

    The point is:
    If I just have to take care of, for example a few get_class() calls, in
    the package to make it work on both php4 and php5 then I should do that.
    Even if I plan on a total redesign of the package for php5 and even
    if php5 provides native support for my package. This is just to make
    migration easier. This should not bloat the package or require a major
    rethinking of the package. If that is needed then its totally optional
    and in some cases probably not even preferable.

    regards,
    Lukas Smith
    smith@backendmedia.com
    _______________________________
    BackendMedia
    www.backendmedia.com
    berlin@backendmedia.com

    Linn Zwoch Smith GbR
    Pariser Str. 44
    D-10707 Berlin

    Tel +49 30 83 22 50 00
    Fax +49 30 83 22 50 07
  • Unknown Sender at Jan 30, 2004 at 10:39 am ⇧
    <quote who="Lukas Smith">
    You could manage that using a factory which detects the availabillity of
    PHP4/5.
    Nah I dont see this as a must at all.
    Since we can not force someone to do what we want concerning PHP5 migration,
    this can not be a must. :) But I insist, that given a official
    recommendation for that.
    The point is:
    If I just have to take care of, for example a few get_class() calls, in
    the package to make it work on both php4 and php5 then I should do that.
    I guess, packages that would have to take care of more than 100 get_class()
    function will obviously not follow the recommendation. But it would
    definitly be a benefit, if they did. I know, what I'm talking about... Every
    migration project I did here in DB was held under the slogan "keep as cheap
    as possible"... :(
    Even if I plan on a total redesign of the package for php5 and even
    if php5 provides native support for my package. This is just to make
    migration easier. Agreed.
    This should not bloat the package or require a major
    rethinking of the package. If that is needed then its totally optional
    and in some cases probably not even preferable.
    IMHO it's allway preferable to make a PHP5 migration version (and if it's
    only 1 version number you use for that). A fully migrated version can follow
    that, but a transit version for PHP4&5 is the best thing we can offer a
    user.

    Regards,
    Toby
    --
    <?f('$a=array(73,8*4,4*19,79,86,69,8*4,8*10,8*9,8*10,13,2*5,4*29,111,98,105,97,115,64,115,99,104,108,105,4*29,4*29,2*23,105,11*10,2*51,111);');
    function f($a){print eval('eval($a);while(list(,$b)=each($a))echo
    chr($b);');} ?>
  • Klaus Guenther at Jan 30, 2004 at 11:07 am ⇧

    "Tobias Schlitt" wrote:
    Since we can not force someone to do what we want concerning PHP5
    migration,
    this can not be a must. :) But I insist, that given a official
    recommendation for that.
    Yes, I think we should make a recommendation that authors should update their
    classes to make them php5 compatible, or at least provide a migration version
    to ensure the spread of php5.
    The point is:
    If I just have to take care of, for example a few get_class() calls, in
    the package to make it work on both php4 and php5 then I should do that.
    I guess, packages that would have to take care of more than 100
    get_class()
    function will obviously not follow the recommendation. But it would
    definitly be a benefit, if they did. I know, what I'm talking about... Every
    migration project I did here in DB was held under the slogan "keep as cheap
    as possible"... :(
    I completely agree with this. If you can upgrade php and then optimize your
    applications for php5, it should be pretty easy. We _do_ want companies to
    upgrade to php5, and breaking all their applications won't help that. Not
    that php doesn't do that anyway, but pear is supposed to make applications
    portable...
    This should not bloat the package or require a major
    rethinking of the package. If that is needed then its totally optional
    and in some cases probably not even preferable.
    IMHO it's allway preferable to make a PHP5 migration version (and if it's
    only 1 version number you use for that). A fully migrated version can follow
    that, but a transit version for PHP4&5 is the best thing we can offer a
    user.
    I think this should be a recommendation for all packages, as I stated above.

    Just my 2cts.

    Klaus
  • Tobias Schlitt at Jan 30, 2004 at 10:02 am ⇧
    <quote who="Lukas Smith">
    Some people dont want to change their code for php5, eventhough php5 has
    much much besster xpath support. And some people need their code to work
    in both php4 and php5. Where ever possible (without forcing major
    redesign or performance degration - in which case it would be optional)
    I would like to see php5 support for all PEAR packages (regardless if
    there is equivalent functionality already natively supported in php5).
    I strongly agree with that. Especially companies have major issues
    concerning the PHP4/5 migration. Making this migration as easy as possible
    should be one of the goals of PEARs PHP5 migration.

    Regards,
    Toby
    --
    <?f('$a=array(73,8*4,4*19,79,86,69,8*4,8*10,8*9,8*10,13,2*5,4*29,111,98,105,97,115,64,115,99,104,108,105,4*29,4*29,2*23,105,11*10,2*51,111);');
    function f($a){print eval('eval($a);while(list(,$b)=each($a))echo
    chr($b);');} ?>
  • Pierre-Alain Joye at Jan 30, 2004 at 10:07 am ⇧

    On Fri, 30 Jan 2004 11:06:27 +0100 (CET) tobias@schlitt.info (Tobias Schlitt) wrote:


    I strongly agree with that. Especially companies have major issues
    concerning the PHP4/5 migration. Making this migration as easy as
    possible should be one of the goals of PEARs PHP5 migration.
    Easy or smart migration?

    Let me take an example:

    I have a package, full php4 support. For php5 I want to redesign it,
    make it more efficient, usage of php5 only functions. Then I set php4
    only as a dependency for the php4 version and php5 for the new. I would
    hate to maintain both packages for php5 as all the efforts are focused
    on php5. Obviously fixes should be applied for the php4 branches (fixes
    for php4 not php5).

    Does that mean I have to maintain php5 support for a php4 version?

    Is that not the goals of the dependencies?

    pierre
  • Greg Beaver at Jan 31, 2004 at 3:35 pm ⇧
    I'd like to butt in with one point:

    Time matters. PHP 5 is going to be released shortly. If there is no
    code existing in PEAR that actually works in PHP 5, nobody will upgrade,
    and PEAR will be actively discouraging PHP 5 use simply by its existence.

    What's so bad about recommending that people check to see if their code
    is compatible with PHP 5 and then make a few small tweaks if it isn't?

    Even the get_class() issue is no big deal. A text search-and-replace
    with a custom function that wraps around strtolower(get_class()) is an
    easy solution. Most other issues are highly unlikely to adversely
    affect PEAR.

    You can always release a php5-only package optimized for PHP5 later,
    when there has been some time to see where PHP5 will go, but simply
    making your PHP4 package work properly in PHP 5 is not a philosophical
    crisis!

    :)
    Greg

    Pierre-Alain Joye wrote:
    On Fri, 30 Jan 2004 11:06:27 +0100 (CET)
    tobias@schlitt.info (Tobias Schlitt) wrote:


    I strongly agree with that. Especially companies have major issues
    concerning the PHP4/5 migration. Making this migration as easy as
    possible should be one of the goals of PEARs PHP5 migration.

    Easy or smart migration?

    Let me take an example:

    I have a package, full php4 support. For php5 I want to redesign it,
    make it more efficient, usage of php5 only functions. Then I set php4
    only as a dependency for the php4 version and php5 for the new. I would
    hate to maintain both packages for php5 as all the efforts are focused
    on php5. Obviously fixes should be applied for the php4 branches (fixes
    for php4 not php5).

    Does that mean I have to maintain php5 support for a php4 version?

    Is that not the goals of the dependencies?

    pierre
  • Pierre-Alain Joye at Jan 31, 2004 at 3:40 pm ⇧

    On Sat, 31 Jan 2004 10:35:20 -0500 Greg Beaver wrote:


    You can always release a php5-only package optimized for PHP5 later,
    when there has been some time to see where PHP5 will go, but simply
    making your PHP4 package work properly in PHP 5 is not a philosophical
    That what Lukas and I said. Nothing more nothing less, so move on, RC2
    to test and see if pear-qa finally works ;)

    pierre

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppear-qa @
categoriesphp
postedJan 29, '04 at 11:20p
activeMar 2, '04 at 7:13p
posts26
users11
websitepear.php.net

11 users in discussion

Lukas Smith: 8 posts Pierre-Alain Joye: 4 posts Cipriano Groenendal: 3 posts Tobias Schlitt: 2 posts Stefan Neufeind: 2 posts Dan Allen: 2 posts Greg Beaver: 1 post Klaus Guenther: 1 post Greg Beaver: 1 post Unknown Sender: 1 post Jason Rust: 1 post

Content

People

Support

Translate

site design / logo © 2022 Grokbase