Re: [PHP-DEV] [PATCH] Add option to disable POST data processing

2010-12-19 Thread Pierre Joye
hi, That was one other thing related to this addition, not specifically the main reason why I think this addition is not as good as expected. Especially as as Gustavo said as well, it is possible to do it using a nice and clean APIs instead of adding yet another cryptic ini setting. I'm not sayin

Re: [PHP-DEV] Traits and Properties

2010-12-19 Thread Stefan Marr
Hi Matthew: On 19 Dec 2010, at 17:22, Matthew Weier O'Phinney wrote: > Exactly. I wouldn't default to public on conflicts, though -- just with > the highest declared visibility (e.g., if one trait defines as private > and the other as protected, protected wins). I am currently actually implementin

Re: [PHP-DEV] RFC: Selecting Namespaces and Tag styles at include time. ( was Re: PHP Dev RFC Selecting Namespaces and Tag styles at include time.)

2010-12-19 Thread Matthew Weier O'Phinney
On 2010-12-17, Michael Morris wrote: > --0016e6daa93aab9e2004979f11fa > Content-Type: text/plain; charset=ISO-8859-1 > > I've been giving some thought to the implication of my off the cuff > addition of PHP_TAGS_NONE to the modes allowed and what should > logically go with that. If tag style can b

Re: [PHP-DEV] Traits and Properties

2010-12-19 Thread Matthew Weier O'Phinney
On 2010-12-18, Stefan Marr wrote: > On 16 Dec 2010, at 23:31, Larry Garfield wrote: > > - When the visibility collides, should we be folding to the most > > restrictive or least restrictive? I'm not sure myself; I'm more > > interested in your reasoning for going for most-restrictive. > So, in ge

Re: [PHP-DEV] [PATCH] SplObjectStorage::removeCommon and removeUncommon

2010-12-19 Thread Hannes Magnússon
On Sun, Dec 19, 2010 at 16:16, Gustavo Lopes wrote: > On Sun, 19 Dec 2010 15:12:17 -, Hannes Magnússon > wrote: > >> On Sun, Dec 19, 2010 at 16:05, Gustavo Lopes >> wrote: >>> >>> On Sun, 19 Dec 2010 15:03:22 -, Hannes Magnússon >>> wrote: >>> On Sun, Dec 19, 2010 at 15:49, Gustavo

Re: [PHP-DEV] [PATCH] SplObjectStorage::removeCommon and removeUncommon

2010-12-19 Thread Gustavo Lopes
On Sun, 19 Dec 2010 15:12:17 -, Hannes Magnússon wrote: On Sun, Dec 19, 2010 at 16:05, Gustavo Lopes wrote: On Sun, 19 Dec 2010 15:03:22 -, Hannes Magnússon wrote: On Sun, Dec 19, 2010 at 15:49, Gustavo Lopes wrote: On Sun, 19 Dec 2010 05:33:56 -, Matthew Turland wrot

Re: [PHP-DEV] [PATCH] SplObjectStorage::removeCommon and removeUncommon

2010-12-19 Thread Hannes Magnússon
On Sun, Dec 19, 2010 at 15:49, Gustavo Lopes wrote: > On Sun, 19 Dec 2010 05:33:56 -, Matthew Turland > wrote: > >> Attached are source/test and manual patches for the addition of two >> methods to the SplObjectStorage class. These methods, removeCommon and >> removeUncommon, add support for

Re: [PHP-DEV] [PATCH] SplObjectStorage::removeCommon and removeUncommon

2010-12-19 Thread Gustavo Lopes
On Sun, 19 Dec 2010 05:33:56 -, Matthew Turland wrote: Attached are source/test and manual patches for the addition of two methods to the SplObjectStorage class. These methods, removeCommon and removeUncommon, add support for the difference and intersection set operations, respectively. I

Re: [PHP-DEV] [path] fixing errors, take 2

2010-12-19 Thread Hannes Magnússon
On Sun, Dec 19, 2010 at 10:56, Stas Malyshev wrote: > Hi! > >> AFAICT from the patch.. >> if (@strpos()) {} else { var_dump(error_get_last()); } >> will give you the last error that happened before strpos()? > > Hmm... that unfortunately depends on ignore_repeated_errors, I didn't see > this use c

Re: [PHP-DEV] [path] fixing errors, take 2

2010-12-19 Thread Stas Malyshev
Hi! AFAICT from the patch.. if (@strpos()) {} else { var_dump(error_get_last()); } will give you the last error that happened before strpos()? Hmm... that unfortunately depends on ignore_repeated_errors, I didn't see this use case. With error_get_last() we probably can't fix it since it requ

Re: [PHP-DEV] [path] fixing errors, take 2

2010-12-19 Thread Hannes Magnússon
On Sun, Dec 19, 2010 at 04:31, Stas Malyshev wrote: > Hi! > > Since my first attempt to make error reporting in PHP more efficient (see > epic thread here: > http://www.pubbs.net/200908/php/49633-php-dev-patch-error-masks.html) I > thought about another approach to fixing it. > This approach elimi