Comments for "Diff"

» Submit Your Comment
Comments are only accepted during the "Proposal" phase. This proposal is currently in the "Finished" phase.
» Comments
  • Stefan Neufeind  [2004-04-04 18:29 UTC]

    Had a quick look at the source, and I like the idea of having such functionality in pear, so that you can also compare two text-blocks directly in memory or similar. Since it's already in use by Horde I asume the package runs smooth :-))
    However, do you think it should just be used for diffing text? Or could maybe a more general package be founded which then also contained functions to do e.g. a DeltaV-diff on binary files (as it is done for Subversion) etc.? Though I haven't yet occupied myself with the algos, but it might be handy sometimes - and we wouldn't need an additional package for binary diffs.
  • Paul Jones  [2004-04-04 18:41 UTC]

    Stefan Neuefeind wrote:

    > However, do you think it should just be
    > used for diffing text? Or could maybe a
    > more general package be founded which
    > then also contained functions to do e.g.
    > a DeltaV-diff on binary files (as it is
    > done for Subversion) etc.? Though I
    > haven't yet occupied myself with the
    > algos, but it might be handy sometimes -
    > and we wouldn't need an additional
    > package for binary diffs.

    As I did not write the code, I cannot say with any authority what is planned for Text_Diff. Please recall that it originates from Horde and was built for Horde's needs. With that in mind, I think it's fair to say that the package will have to be accepted or declined as it is, without significant changes in purpose or API, unless those changes cascade forward from Horde. Chuck or Jon will be happy to correct or emphasize that statement, I'm sure.

    Having said that, I don't think it would be too much of a stretch to add another class to this package in the same way Diff3.php (for three-way diffs) is added. That is, to use the "text" parser for binaries should not be either difficult, although it might initially be counterintuitive organizationally. (And what PEAR category would it fit into if not "Text"?) Regardless, I'm sure it would have to go through the Horde process, not the PEAR process, to be added.
  • Davey Shafik  [2004-04-04 19:22 UTC]

    I like the idea of this, I personally have had occassion to want something like this.

    Documentation should be kept on the PEAR Website IMNSHO.

    - Davey
  • Paul Jones  [2004-04-04 21:23 UTC]

    Davey Shafik wrote:

    > Documentation should be kept on the PEAR Website IMNSHO.

    Davey, thank you for volunteering to convert existing and future documentation to DocBook. ;-)
  • Firman Wandayandi  [2004-04-05 00:42 UTC]

    Why on _check() method did not using PEAR::raiseError() for handling the error. In my opinion there's more comportable to handling error using PEAR_Error, more quite!

    BTW, the functionality might be usefull.
  • Paul Jones  [2004-04-05 01:07 UTC]

    Firman wrote:

    > Why on _check() method did not using PEAR::raiseError() for
    > handling the error. In my opinion there's more comportable to
    > handling error using PEAR_Error, more quite!

    I think this is a Horde-ism. Because the class originates from Horde, they don't expect PEAR_Error to be available. Yes, PEAR_Error gives more flexibility, but Greg Beaver's new Error_Stack may make the trigger_error() call much more useful.
  • Chuck Hagenbuch  [2004-04-05 02:50 UTC]

    A few things:

    - I'd be very happy to make the class structure support binary files, but I'm not sure what the appropriate name would be then, and I don't have the relevant code, so I didn't do it. If someone has code or just future-compatible naming suggestions, I'm all ears.

    - Paul graciously put together this proposal as I've been a bit swamped to do it myself. I fully intend to host the package at pear.horde.org, will have documentation at dev.horde.org, and will upload new builds to pear.php.net as new versions stabilize in CVS. I'd also be thrilled to have docbook documentation hosted on pear.php.net. By the way, anyone who wants to proxy-write proposals for any of the packages at http://cvs.horde.org/cvs.php/framework/ would be very welcome to do so.

    Many thanks to Paul, and thanks for the suggestions so far.
  • Alan Knowles  [2004-04-05 02:59 UTC]

    Serious Cons..
    Reasons.
    - without serious ownership
    - bugs get unleft forever.
    - do you have write access to maintain it in horde?
    - can it be changed to follow pear standards (generally 1class = 1file)

    It sounds a bit like pear would be treated like a deb/rpm repository - where we just package files..

    ** I like the class BTW.. - but am a bit concerned about how it will/wont be maintained..
  • Paul Jones  [2004-04-12 19:15 UTC]

    If there are no more comments on this, I will set it into "call for votes" mode.