deep investigation of PHP_Callback

Hi,

As your newly elected president, I must step in here.  The
debate over
PHP_Callback is approaching an emotional flame war.  Anyone
who posts a
flame reply after this email will be sent to the principal's
office and
given detention.  I mean it.

As for PHP_Callback, I did some work to test the assertions
of those
involved.  I created two scripts.  Here is the first
script:

callable.php
<?php
$a = array('myclass', 'myfunc');
if (!is_callable($a)) {
    throw new BadMethodCallException('test');
}
?>

and here is the second:

phpcallback.php
<?php
require_once 'PHP/Callback.php';
$p = new PHP_Callback('myclass', 'myfunc');
?>

Then, I ran apache benchmark on them.  For comparison, I ran
it on a
static index.html file that comes with apache2.  Here are
the results:

index.html: Requests per second:    3269.72 [#/sec] (mean)
callable.php: Requests per second:    1066.97 [#/sec]
(mean)
phpcallback.php: Requests per second:    303.20 [#/sec]
(mean)

Using PHP_Callback was 3.5 times slower than the native PHP,
with a
difference of 1 line of extra code in the native PHP.

This of course, is the simplest and an unlikely case.  I
estimate that
probably most scripts will be instantiating at most 100
PHP_Callback or
processing 100 callbacks.  I modified the scripts as
follows:

callable.php
<?php
$a = array('myclass', 'myfunc');
for ($i = 0; $i < 100; $i++) {
    try {
        if (!is_callable($a)) {
            throw new BadMethodCallException('test');
        }
    } catch (Exception $e) {
       
    }
}
?>

phpcallback.php
<?php
require_once 'PHP/Callback.php';
for ($i = 0; $i < 100; $i++) {
    try {
        $p = new PHP_Callback('myclass', 'myfunc');
    } catch (Exception $e) {
       
    }
}
?>

index.html: Requests per second:    3410.66 [#/sec] (mean)
callable.php: Requests per second:    524.53 [#/sec] (mean)
phpcallback.php: Requests per second:    159.20 [#/sec]
(mean)

In this case, using PHP_Callback was 3.29 times slower, so
with volume,
the inefficiency decreases slightly, but is still a marked
reduction in
speed.

One argument for using PHP_Callback is that it allows
validation at
callback creation.  The scripts I used for benchmarking show
that this
is a difference of 1 line of code, and a reduction in
efficiency of 3x.

Another argument for using PHP_Callback is that it unifies
execution of
a callback.  Here is the difference:

old:
<?php
call_user_func_array($callback, array('param1', 'param2'));
?>

new:
<?php
$callback->execute('param1', 'param2');
?>

To test this, I used these scripts:

callable.php
<?php
require_once 'PHP/Callback.php';
function myfunc($a, $b)
{
    echo $a.$b;
}
$p = new PHP_Callback('myfunc');
$a = 'myfunc';
for ($i = 0; $i < 10000; $i++) {
    call_user_func_array($a, array('hi', ' there'));
}
?>

phpcallback.php
<?php
require_once 'PHP/Callback.php';
function myfunc($a, $b)
{
    echo $a.$b;
}
$p = new PHP_Callback('myfunc');
for ($i = 0; $i < 10000; $i++) {
    $p->execute('hi', ' there');
}
?>

Note that the PHP_Callback creation time is evened out, and
so the
benchmarking is truly testing the time it takes to execute a
callback.

Again, the efficiency lost is tremendous.

index.html: Requests per second:    3378.96 [#/sec] (mean)
callable.php: Requests per second:    30.20 [#/sec] (mean)
phpcallback.php: Requests per second:    14.53 [#/sec]
(mean)

PHP_Callback is twice as slow as native PHP, and the
difference between
the two calls is a few characters.

The third argument is that it can be used as a type hint in
a function
or method.  This results in a difference of this code:

function blah(PHP_Callback $callback)
{
     $callback->execute(...)
}

and

function blah($callback)
{
    if (!is_callable($callback)) {
        throw new BadMethodCallException(...)
    }
    call_user_func_array($callback, array(...));
}

Here, we require three extra lines of code to validate the
callback, and
it is 3 times as efficient.  In addition, if there is any
complex
callback validation (i.e. it must be an array with an object
that is an
instanceof class "Blah"), there is no advantage to
using PHP_Callback,
and it actually becomes difficult to figure out how to
validate the
callback.

Finally, type-hinting is a fatal error in PHP, and cannot be
caught and
handled, although it has become a recoverable fatal error in
PHP 5.2,
this still kicks execution to the global scope.

In short, I see no advantages to using PHP_Callback over
native PHP.  Is
there something I missed Travis?

I'm sorry you received such a sour reception initially, I
hope you can
forgive our lack of patience.  All of the seasoned PEAR
developers are
going to learn from this experience and act differently in
the future.

Thanks,
Greg

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Howdy all,

If you'll indulge me, I'm going to respond to this out of
order.


Gregory Beaver wrote:
> In short, I see no advantages to using PHP_Callback
over native PHP.  Is
> there something I missed Travis?
>   

Greg, excellent due diligence on providing some benchmarks
on how 
PHP_Callback works against straight PHP.  I think, however,
you've 
missed the point of this code entirely.  It's there to
provide a OO 
wrapper - for those choosing to use an OO methodology in PHP
- to a core 
"type" for which there is no way other than
peppering the code with if 
statements to determine what is happening.  This object
allows for DRY 
programming by encapsulating that checking for you.  It's
not meant to 
be as fast or faster than core PHP code, as no wrapper is. 
The shear 
act of wrapping anything in an object or function
automatically slows 
PHP code down.  Changing this:

    echo strtolower('Hello World');

to this:

    function msg($string) {
        return strtolower($string);
    }
    echo msg('Hello World');

increases the execution time by approximately 20%

proc.php:Requests per second:    697.25 [#/sec] (mean)
func.php:Requests per second:    574.52 [#/sec] (mean)

If speed is the ultimate goal, PEAR should be a series of
procedural 
includes that run various functions.  Given that I don't
believe speed 
is the ultimate goal, I don't see this as an issue.  Speed
is sacrificed 
for readability, encapsulation, and in the case of object
oriented code 
polymorphism.

As an interesting foot note to these tests, I put together
the following 
object to see how it fared compared to the two methods above
with the 
certain expectation that it would run more slowly than the
function:

    class MyString {
        private $_var = '';
        function __construct($string) {
            $this->_var = strtolower($string);
        }

        function output() {
            return $this->_var;
        }
    }

    $obj = new MyString('Hello World');
    echo $obj->output();

The result kind of surprised me:

proc.php:Requests per second:    697.25 [#/sec] (mean)
func.php:Requests per second:    574.52 [#/sec] (mean)
class.php:Requests per second:    614.61 [#/sec] (mean)

Anyhow, back on topic ...


> Using PHP_Callback was 3.5 times slower than the native
PHP, with a
> difference of 1 line of extra code in the native PHP.
>
> ... snip ...
>
> In this case, using PHP_Callback was 3.29 times slower,
so with volume,
> the inefficiency decreases slightly, but is still a
marked reduction in
> speed.
>   

I disagree with the way these benchmarks were done.  Of
course, 
depending on what you're after you can make any benchmark
look better or 
worst than another, so this is 100% subjective.  That
said...

PHP_Callback allows you to adhere to the DRY principle.  By
passing this 
object around, you know you have a valid callback without
having to do 
is_callable() on the variable.  With that in mind, assuming
you use a 
single callback one times within the code, you will have one

instantiation of PHP_Callback with 100 calls to execute(),
while the 
straight procedural code will have one setup of the variable
with 100 
if() statements and 100 call_user_func_array() calls.

Using this assumption as the base, I put together a quick
script to 
generate PHP files to benchmark against (script is available
at  
http://plumb.
domain51.com/pear/gen.phps).

Using the following ab command I got these results:

ab -c 100 -t 60 http://localhost/path/to/[proc|pear].php > proc|pear.ab

proc.php:Requests per second:    165.57 [#/sec] (mean)
pear.php:Requests per second:    111.89 [#/sec] (mean)

Using this as the code to benchmark against, PHP_Callback
(pear) code is 
roughly 33% slower, not 320% - 350%.  It is still a sizable
amount and 
one to be taken into account when optimizing code, but given
the other 
areas where code is almost certainly not optimized within
any given 
project, this would probably be one of the last areas you
were start 
trying to squeeze the milliseconds out of the code.

It should also be noted that proc.php is 3 times the size of
pear.php 
(303 vs 104 lines) as it has to perform an if() at each
execution. 

> The third argument is that it can be used as a type
hint in a function
> or method.  This results in a difference of this code:
>
> ... snip ...
>
> Here, we require three extra lines of code to validate
the callback, and
> it is 3 times as efficient.  In addition, if there is
any complex
> callback validation (i.e. it must be an array with an
object that is an
> instanceof class "Blah"), there is no
advantage to using PHP_Callback,
> and it actually becomes difficult to figure out how to
validate the
> callback.

In the case of complex validation, it's quite simple to
Decorate 
PHP_Callback and make your new MyGreatCallbackValidator
perform the 
additional functionality for you.  This can be done by
containing a 
PHP_Callback object (my preference) or by extending it.


> Finally, type-hinting is a fatal error in PHP, and
cannot be caught and
> handled, although it has become a recoverable fatal
error in PHP 5.2,
> this still kicks execution to the global scope.

If you're type hinting and the wrong variable type is passed
in, 
wouldn't you want PHP to throw a fatal error?  Something
unexpected - 
and generally unrecoverable - has just happened; something
that 
according to the design that's been laid out should have
never 
happened.  One of the points of type hinting is to say
"this method will 
only ever take this type".  In my opinion, if you
condition there's a 
much larger issue at play here than whether a fatal error is
thrown or not.


> I'm sorry you received such a sour reception initially,
I hope you can
> forgive our lack of patience.  All of the seasoned PEAR
developers are
> going to learn from this experience and act differently
in the future.
>   

Thanks for your apology, Greg.  It's completely unnecessary,
but 
appreciated.  As noted by one of those who left comments,
this is an 
extremely simple package and one that nearly any PHP coder
could put 
together in very short order.  My biggest concern is what
would have 
happened had this package been proposed by someone new to
the PEAR 
community and/or PHP in general?  Anyone coming from an OO
background 
would have seen this as an obviously useful package and just
considered 
it an oversight that it wasn't already available.  That
person, who 
might have even learned a thing or two about PHP via code
available from 
PEAR, would have been excited about the prospect of being
able to 
contribute something back to the community.  To have their
contribution 
greeted by having it declared "useless" would have
been dispiriting to 
say the least, and at worst might discouraged them from
future 
contributions.

As it stands, I have a few other ideas up my sleeves that as
time 
permits will make their way into PEPr... though Alexey took
the 
PHP_String from me. 

-Travis

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Travis Swicegood wrote:

> Thanks for your apology, Greg.  It's completely
unnecessary, but 
> appreciated.  As noted by one of those who left
comments, this is an 
> extremely simple package and one that nearly any PHP
coder could put 
> together in very short order.  My biggest concern is
what would have 
> happened had this package been proposed by someone new
to the PEAR 
> community and/or PHP in general?  Anyone coming from an
OO background 
> would have seen this as an obviously useful package and
just considered 
> it an oversight that it wasn't already available.  That
person, who 
> might have even learned a thing or two about PHP via
code available from 
> PEAR, would have been excited about the prospect of
being able to 
> contribute something back to the community.  To have
their contribution 
> greeted by having it declared "useless" would
have been dispiriting to 
> say the least, and at worst might discouraged them from
future 
> contributions.

Harsh has it might have been to this kind of person, they
might have 
also learned something in the process about how to think
when you are 
developing PHP.

That being said, I personally think that PHP_Callback can be
quite 
useful in exactly the kind of case you describe: you have a
callback 
that would frequently have to be checked prior to calling
instead of at 
definition time.

What Bertrand and Alexey were worried about was that this
package would 
become the defacto standard for all callbacks implemented in
PEAR, which 
would quickly add up to quite a lot of overhead. So the key
things for 
me is to ensure that people realize when it makes sense to
use this 
package and when it doesn't. This also ties in to the
general informal 
guideline in PEAR that you do not put dependencies in order
to save a 
minimal amount of code (let's but the number somewhere
around 50 lines). 
This general guideline would probably prevent the worst of
abuses of 
PHP_Callback.

regards,
Lukas

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Hi,

Lukas Kahwe Smith wrote:
> What Bertrand and Alexey were worried about was that
this package would 
> become the defacto standard for all callbacks
implemented in PEAR, which 
> would quickly add up to quite a lot of overhead. So the
key things for 
> me is to ensure that people realize when it makes sense
to use this 
> package and when it doesn't. This also ties in to the
general informal 
> guideline in PEAR that you do not put dependencies in
order to save a 
> minimal amount of code (let's but the number somewhere
around 50 lines). 
> This general guideline would probably prevent the worst
of abuses of 
> PHP_Callback.

I won't speak for Bertrand since we didn't discuss this with
him, but my main 
reasons against was the following:
1) We accept packages that solve specific user problems. I
don't see a problem 
being solved here in the first place.
2) Traditionally PEAR didn't accept packages that just wrap
native PHP functions 
in fake OO code. If that was not the case we'd already have
PHP_Callback / 
PHP_String / PHP_Sprintf and whatever else.
3) We all fondly remember PEAR_Error. 'nuff said.

Also this whole discussion wasted much more of everybody's
time than writing 
this gem of a package did. I won't repeat this error and
will in similar cases 
wait with arguments until the voting phase. That'll be much
more fun.

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

On 5/6/07, Alexey Borzov <borz_offcs.msu.su> wrote:
> Hi,
>
> Lukas Kahwe Smith wrote:
> > What Bertrand and Alexey were worried about was
that this package would
> > become the defacto standard for all callbacks
implemented in PEAR, which
> > would quickly add up to quite a lot of overhead.
So the key things for
> > me is to ensure that people realize when it makes
sense to use this
> > package and when it doesn't. This also ties in to
the general informal
> > guideline in PEAR that you do not put dependencies
in order to save a
> > minimal amount of code (let's but the number
somewhere around 50 lines).
> > This general guideline would probably prevent the
worst of abuses of
> > PHP_Callback.
>
> I won't speak for Bertrand since we didn't discuss this
with him, but my main
> reasons against was the following:
> 1) We accept packages that solve specific user
problems. I don't see a problem
> being solved here in the first place.
> 2) Traditionally PEAR didn't accept packages that just
wrap native PHP functions
> in fake OO code. If that was not the case we'd already
have PHP_Callback /
> PHP_String / PHP_Sprintf and whatever else.
> 3) We all fondly remember PEAR_Error. 'nuff said.
>
> Also this whole discussion wasted much more of
everybody's time than writing
> this gem of a package did. I won't repeat this error
and will in similar cases
> wait with arguments until the voting phase. That'll be
much more fun.
>

Waiting to comment until the voting phase isn't how the
system is
supposed to work.

-- 
Justin Patrin

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Hi,

Justin Patrin wrote:
>> Also this whole discussion wasted much more of
everybody's time than 
>> writing
>> this gem of a package did. I won't repeat this
error and will in 
>> similar cases
>> wait with arguments until the voting phase. That'll
be much more fun.
> 
> Waiting to comment until the voting phase isn't how the
system is
> supposed to work.

I think there is a big gap between how the system is
supposed to work and how it 
works:
1) People put packages up for public criticism then act all
offended when they 
receive said criticism.
2) Lots of developers only complain about docblocks /
licenses / CS. A bot can 
be written that will do exactly the same! People are either
unwilling to look 
into the actual workings of the package or unwilling to
"offend" their fellow 
developers.

Thus me keeping my comments for "easily offended"
developers until the voting 
phase won't make this gap *much* wider, I suppose...

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Le 6 mai 07 à 02:22, Travis Swicegood a écrit :

>
> Using this assumption as the base, I put together a
quick script to  
> generate PHP files to benchmark against (script is
available at   
> http://plumb.
domain51.com/pear/gen.phps).
>
> Using the following ab command I got these results:
>
> ab -c 100 -t 60 http://localhost/path/to/[proc|pear].php > proc| 
> pear.ab
>
> proc.php:Requests per second:    165.57 [#/sec] (mean)
> pear.php:Requests per second:    111.89 [#/sec] (mean)
>
> Using this as the code to benchmark against,
PHP_Callback (pear)  
> code is roughly 33% slower, not 320% - 350%.  It is
still a sizable  
> amount and one to be taken into account when optimizing
code, but  
> given the other areas where code is almost certainly
not optimized  
> within any given project, this would probably be one of
the last  
> areas you were start trying to squeeze the milliseconds
out of the  
> code.

Here are my results for your scripts on a MacBookPro 2.33
Ghz Core Duo:

Proc: Requests per second:    3127.15 [#/sec] (mean)
Pear: Requests per second:    585.43 [#/sec] (mean)

That's 5 times slower. It is, I think, a lot closer to truth
than  
your own results...
For other tests, I am in line with Greg's results.

--
Bertrand Mansion
Mamasam
Work : http://www.mamasam.com
Blog : http://golgote.freeflux.n
et

--
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Le 6 mai 07 à 09:25, Alexey Borzov a écrit :

> Hi,
>
> Justin Patrin wrote:
>>> Also this whole discussion wasted much more of
everybody's time  
>>> than writing
>>> this gem of a package did. I won't repeat this
error and will in  
>>> similar cases
>>> wait with arguments until the voting phase.
That'll be much more  
>>> fun.
>> Waiting to comment until the voting phase isn't how
the system is
>> supposed to work.
>
> I think there is a big gap between how the system is
supposed to  
> work and how it works:
> 1) People put packages up for public criticism then act
all  
> offended when they receive said criticism.
> 2) Lots of developers only complain about docblocks /
licenses /  
> CS. A bot can be written that will do exactly the same!
People are  
> either unwilling to look into the actual workings of
the package or  
> unwilling to "offend" their fellow
developers.
>
> Thus me keeping my comments for "easily
offended" developers until  
> the voting phase won't make this gap *much* wider, I
suppose...

I agree with that. When Travis proposed his package, he
should have  
expected criticism. I found his package useless, I said so.
I don't  
know if there is a difference between "useless"
and "not useful" in  
English, maybe "useless" is stronger. Now, I am a
star in his blog.  
Apparently, he says I have made an English mistake in my
comment on  
his proposal. I can live with that, I ain't no English
expert, but  
that's not the best way to get accepted in a community of
developers  
like PEAR in my opinion.


PS: Here is my comment
"This is useless. PHP callbacks are already quite
comprehensible and  
don't need to be complicated."
Any native English speaker could tell me what's wrong in
this sentence ?


--
Bertrand Mansion
Mamasam
Work : http://www.mamasam.com
Blog : http://golgote.freeflux.n
et

--
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

On Sunday 06 May 2007 09:05:17 Alexey Borzov wrote:

> 2) Traditionally PEAR didn't accept packages that just
wrap native PHP
> functions in fake OO code. If that was not the case
we'd already have
> PHP_Callback / PHP_String / PHP_Sprintf and whatever
else.

I think the current discussion is closely connect to the
change from PHP4 
("traditionally" programming) and PHP5 (OOP).
Nevertheless i think everyone 
should have the freedom to program in the way she or he
likes. So maybe a 
solution would be to introduce a new Top Level package
calles "Wrapper" where 
such packages could go.
I personally would like to see some OOP wrapper but i can
also clearly 
understand, because of performance reasons, that someone
does not want to use 
this package.
Regards
	Elmar

-- 
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.1 (GNU/Linux)

mQGiBEJ6ZWERBADFODpdX4FA3HJzqK7Cm+iaOqiZ2ffbjO3nQ7uWMX+1mLKg
bksD
eP7oNn3LmrxgRT8JSyTXCAwvEg83vgvtDc6+JSmF0oIkS54CQOIphAv4U5ke
jPbr
l3WNH7eFarN8rMICbCF0gnz/DltnytMLaTVJC6PszcV8gD1hNY4j1bt+rwCg
nEDE
BazL6TMYGixBdNgUsOIAoykD/2+m3Z98Ky+Q+RVa6XGfKyK/JZjm2z7sdwOX
Zlx/
3vEz0SOpJX0hrGNpMuwfBfX1lNtNwnPxOB0MZg85Fn0sAFAsS+B4giSwRiqY
LUvU
OCqjtGOnyyyiilsNAKLG1J/1UvaeYX2bl7lvKOYzzm0ypkuHtA+znNJ2zeER
AYVP
U2E4BADFGp0BSFZnQ5RTvoITHzUWGgSaMszwI4uwr+sLc8F75EvY4HAQkJXc
1aBE
IjbCfrmYApenEKJv/ZFbq4eh+7jZxN1mKJRpcHRnsdsWyYymnCuLebfF3Da7
IBLt
ge6oP2geFGfVUUrd8n62J6zCFz+EsjrRCRd27zO4GSiHkDjgarQmRWxtYXIg
UGl0
c2Noa2UgPGVsbWFyLnBpdHNjaGtlQGdteC5kZT6IXgQTEQIAHgUCQnplYQIb
AwYL
CQgHAwIDFQIDAxYCAQIeAQIXgAAKCRA2BQNGBBXKlL57AJ9SiDe9Ol5N1jFD
/1Nd
DwC1UmfHCACfZ6AFrDyjgNk7aL7kTa5Fe9ip7sq5BA0EQnpm5xAQAIDoitHg
vE3y
poHW+Ws0NXteo/d3cuw03BpP9WHQuFFpAJsk2h0/7pi8CT0Hf+ympdXCvris
rp2w
gbKxCJDjBNVdY6b3bFbQuzNcvKZzJqUXixNd0HJ2ml+lIIdOCuttzOEUhHKq
/zkK
c/mrXWxgC+Iy0d+lapPV3++zaqGi8brJuvJw7k4Hzked9kEzWm/vY9BXXF/e
1F6/
LHiWJQqbJ342uUjML+wmhdQeJkeuQ5Evo5B60lXrvnGllmdH36W6IGZO2DMA
X8Hn
Nhe/UrGeqwff+HL55qGf350LhJX3+JYlP1BM301WGUSNEQW7lrPQ3Duaf066
ZzKp
TdZX8Uvj2uhUyqI7Lu0POCPboo6BAMW9nisxz6m79WJFUxpl8fU1lR//Paae
BZk4
nG8SIVFtS678eaVQrFTtahUjZuUqN9F92TV8Ad1tAG0KzxTfN+qAkQPXwqtu
UJqu
3eZQ5GV1im3hHUWZ1dUCdz5S2OFTLDM4XGOnehZoKlO3IZGNTdymEIvl8wi4
EMyj
itS++zH8m8KZbAnX+qBxqg6jkcejQCPvtJHhqXgHJCoFDVOnm1WrMVzBQTk8
jdtM
llF2GKmU32dak4/lZWKVQwrLODdkRovID3X7H49z4c2B2+yuuVJtR21u1Y0W
V15P
6bXjolXirAHwX/n9Vc4l4y6jEqIyLFl3AAURD/9LhR9gZj1F0ElrIuwg8W0H
c22A
Qg+LLr2mp+DhDE5+y3XndprXxoJpl5bkS0IarkgbXdy9FUntzIC7NsGbLpez
3k4u
wwmKYIlNvB2eP1/QY+CtFzR/hce92oHdCGZK6HTazltKaGRB9go/GlOLNWqb
gAO6
aYFVBWyjRh8LFTNyyuNp+l5oyRPOQyN6wJLgQ513A0RucDQ6d/y0yKGDx1tA
fJti
/S5v0qxke5Mkx2BAteB24WUVWsQB7eOqf5BrGqlVDy/eYQWPUNOWaPCXRRb5
e+2C
uMmo3iF29/0Nh3vBhfqAZwqC//TSoFwEUQx2wdZKEEmz3+wcpqYEZ/LHzhTG
Geat
/r58Ie/oREANQ2GnDhRInYm9dd3/GQlNhZrQzCNTvXdwLYqsC6oqWqOEW1Sj
9l2r
t4zhKQi7+LTawjBC9gVdjH4bf+e4a+h2ttBUOwdmfVsfHNefrTwGVlAuI1uK
L4LF
R5FoiewaL5g9+imbioGYXG2l8+ZDNsRdRQTkRyGW5Vx5rS5Tf9/7oPjl3m3m
OHIY
dg9OHPuFLwaU1AaZXTsA/KjpesQqMtFszMVfDwlm0Zj25GZIvhCX6hpMlCL0
0s9M
APjgadt5NnVaF7ocM8vxSPFaT8LaeO8tXh6Gy7Q2KXwvzWNnwAgiX9vezn7v
2/b0
jeZbNe3LPjnVV1O0AohJBBgRAgAJBQJCembnAhsMAAoJEDYFA0YEFcqUmZwA
oIdP
Nzm0LIjdS3S17oJKd6xhSVi9AJ9mH4bH1KXDWHjT46yIHMxEfRF2hA==
=/rPM
-----END PGP PUBLIC KEY BLOCK-----

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Bertrand Mansion wrote:

> I agree with that. When Travis proposed his package, he
should have 
> expected criticism. I found his package useless, I said
so. I don't know 

I totally agree. I would prefer if some of the criticism
could be 
formulated less harsh (and useless is pretty much the
ultimate nail in 
the coffin kind of language), but honestly I would prefer
this kind of 
criticism over none.

As you go into open source, its one of those lessons to
learn, that you 
have to start to understand that a lot of people will not
wrap their 
comments in nice happy words (especially if they are not
native english 
speakers). You will also learn that you have to be stubborn
to a certain 
degree.

Aside from that, yes we should obviously strive to have a
friendly 
atmosphere, as long as that does not interfere with
producing high 
quality code.

regards,
Lukas

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php