Home > Archive > PHP PEAR Questions and Answers > July 2006 > Re: [PEAR-QA] Re: [PEAR] [ANNOUNCEMENT] File_Find-1.3.0 (stable)Released.
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: [PEAR-QA] Re: [PEAR] [ANNOUNCEMENT] File_Find-1.3.0 (stable)Released.
|
|
| techtonik 2006-07-01, 3:57 am |
| No. Even if it is optional it should be turned on by default. If
you're writing a cross-platform application - it is a feature, bacause
returned result is not system-native, but unified. In addition all
tests passed just fine on linux and windows boxs, so I really doubt if
anything can be broken. This comment and 1.3.0 is just a warning for
real users if they experience any problems. I prefer to get feedback
from these users than trying to grasp over every bit of option nobody
will really care about (except for some guys here, who does not use
this package anyway). I think it is a reasonable desire to make things
logical by default. And do not feed illusions about genious PEAR
distribution and update - if you really care about your application -
you will bundle required packages without possibility of accidental
upgrade. Every package bugfix is a BC break and I can find such things
in almost every release. Once more - possible BC scenario doesn't
worth the efforts, needless to say that this optionnes will make code
more complicated and may affect performance like thousands of
unreplaced double quotes.
I'm out of arguments.
On 7/1/06, Lukas Smith <lsmith@php.net> wrote:
> Arnaud Limbourg wrote:
>
> Yeah sounds like the type of improvement that should be handled via an
> option that defaults to off.
>
> regards,
> Lukas
>
>
--
--t.
| |
| Lukas Smith 2006-07-01, 7:57 am |
| techtonik wrote:
> No. Even if it is optional it should be turned on by default. If
> you're writing a cross-platform application - it is a feature, bacause
> returned result is not system-native, but unified. In addition all
> tests passed just fine on linux and windows boxs, so I really doubt if
> anything can be broken. This comment and 1.3.0 is just a warning for
> real users if they experience any problems. I prefer to get feedback
> from these users than trying to grasp over every bit of option nobody
> will really care about (except for some guys here, who does not use
> this package anyway). I think it is a reasonable desire to make things
> logical by default. And do not feed illusions about genious PEAR
Wrong argument.
> distribution and update - if you really care about your application -
> you will bundle required packages without possibility of accidental
Wrong argument again.
> upgrade. Every package bugfix is a BC break and I can find such things
> in almost every release. Once more - possible BC scenario doesn't
Correct. Yes its a question of categorization, but in most cases its a
fairly straight forward one. If my connect method is unable to connect,
then fixing that is a bugfix and not a BC break. If I change the
behaviour on MDB2 to default to "new_link" in connect then its a BC
break, even if that is the more logical default.
> worth the efforts, needless to say that this optionnes will make code
> more complicated and may affect performance like thousands of
> unreplaced double quotes.
Heh, so a single if is going to kill performance? Not even 10 or 20
should have a relevant effect considering that PEAR code is not meant to
run yahoo.com.
regards,
Lukas
| |
| Lukas Smith 2006-07-01, 7:58 am |
| techtonik wrote:
>
> Ok. It was a bug. I just forgot to mention it was a bug. My File_Find
> method was unable to use streams, which are supported by PHP
> functions. And this was caused by this slash replacement code, which
> affects output in some situations on windows.
So the purpose of the static methods was to leverage the streams API,
but due to this bug this failed? Sounds like a bug fix to me.
>
> If this will not kill the performance then why these holy wars about
> single quotes? Considering that the package methods are meant to be
There are no holy wars about single quotes. Otherwise it would be in the CS.
> called static you need more efforts than add some ifs - probably to
> add additional params to function calls, which are better to be
> reserved for something more useful like stream contexts.
Ok.
regards,
Lukas
|
|
|
|
|