Hi Internals,
as I recently worked with different compilers, and I noticed that we
always check for gcc by default. This means even your /usr/bin/cc is
_not_ gcc, PHP's buildsystem will use gcc if it's found. This is the
default behavior of the AC_PROG_CC macro.
In my opinion, I think if people
I reverted the long changes days ago, but some developers want it back
and others seems doesn't care about it, so I'll apply the patch again
in some hours.
Anyone else have an objection?
2008/10/30 Wez Furlong <[EMAIL PROTECTED]>:
> Just wanted to say that this is the third such commit I've seen
Hello Lukas,
Wednesday, November 12, 2008, 8:14:31 PM, you wrote:
> Hi,
> here are a few questions that need to be answered ASAP.
> If at all possible keep your votes as short as possible. I think all
> of the above topics have been discussed quite a lot on the list. So I
> hope voters can
Hello Stanislav,
thanks :-)
Wednesday, November 12, 2008, 9:58:02 PM, you wrote:
> Hi!
> I want to add error_log option (message_type = 4) which would send the
> message directly to sapi_module.log_message whatever error_log INI
> setting is. This would allow more flexibility in using SAPI
Marcus Boerger wrote:
> And testing is no argument, as you can nicely design so that this
> is not necessary.
For once, testing is not the argument :-) But this is not the place to
discuss what I would like to use this feature for.
I do not see why we added setAccessible() for getValue() and n
On Thu, Nov 13, 2008 at 12:56 PM, Alexey Zakhlestin <[EMAIL PROTECTED]> wrote:
> On Wed, Nov 12, 2008 at 10:14 PM, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote:
>
>> 1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC break
>> will be that "if (extension_loaded('mhash'))" will need
Hello Sebastian,
allowing to read is more than enough. And ofr the record I did not like
that at all. If you need to write to a private variable, then obviously
your class design is wrong. And testing is no argument, as you can nicely
design so that this is not necessary.
marcus
Wednesda
Hi!
This isn't the type of thing that I would naturally expect to find
broken in a .x release, so if we can preserve the old behaviour with
little to no penalty, I suggest we go for that.
I'm not sure we can while preserving new API - since old API gave much
more wiggle room to particular fu
Also cant we some how automate the BC break testing for this (aka
scan all functions that accept an array with the old API in 5.2,
pass it an ArrayObject instance and see what happens and compare
that to 5.3)?
Yes we can ;) That should be not hard to do by looking at ones
having 'a' in pa
Hi!
Can anyone write up a summary of the situation and the options we have?
Sure. A number of array functions in 5.2 accept arrays, but use HASH_OF
to extract array value, which means they automatically accept objects if
the object has working get_properties handler. In 5.3, such function us
Hej everybody,
I had a chat with Stefan about his Traits/Grafts RFC and he suggested we
should rather continue a discussion here.
I really liked to see the Grafts proposal. In traits and regular
inheritance the implementation code of several entities is somehow mixed
and as a result one entities
Gnaaa. Hit the submit button too early. Excuse the rubbish. I will post
the correct mail in a moment.
Christopher
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hej everybody,
I had a chat with Stefan about his Traits/Grafts RFC and he suggested we
should rather continue a discussion here.
I really liked to see the Grafts proposal. In traits and regular
inheritance the implementation code of several entities is somehow mixed
and as a result one entities
On Thu, Nov 13, 2008 at 4:01 PM, Paul Dixon <[EMAIL PROTECTED]> wrote:
> I found and patched a bug in the handling of Digest authentication by
> the SOAP extension (http://bugs.php.net/bug.php?id=46386)
>
> Who do I need to inform to have the patch considered for inclusion?
Post a link to the patc
I found and patched a bug in the handling of Digest authentication by
the SOAP extension (http://bugs.php.net/bug.php?id=46386)
Who do I need to inform to have the patch considered for inclusion?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/un
On Wed, Nov 12, 2008 at 10:14 PM, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote:
> 1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC break
> will be that "if (extension_loaded('mhash'))" will need fixing if mhash is
> removed (answer both)
> I) enable ext/hash by default
+1
> II
Hi.
Lukas Kahwe Smith wrote:
1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC
break will be that "if (extension_loaded('mhash'))" will need fixing if
mhash is removed (answer both)
I) enable ext/hash by default
II) remove ext/mhash
+1 for both
2) deprecate ereg*. ext/er
On Wed Nov 12 02:14 PM, Lukas Kahwe Smith wrote:
> 1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC
> I) enable ext/hash by default
+1
> II) remove ext/mhash
0
> 2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since ext/
+1
> 3) resource constants (choose one
Hi,
Committed, thanks Christian :)
apache2handler, apache2filter, apache, apache_hooks, cli and cgi SAPIs have
been updated.
The following SAPIs need to be updated in PHP_5_3 and HEAD:
aolserver, continuity, litespeed, nsapi, caudium, phttpd, roxen. (I'm CC-ing
known maintainers)
More informa
Lukas Kahwe Smith wrote:
1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC
break will be that "if (extension_loaded('mhash'))" will need fixing if
mhash is removed (answer both)
I) enable ext/hash by default
+1
II) remove ext/mhash
+1
2) deprecate ereg*. ext/ereg is a
Hi,
Can anyone write up a summary of the situation and the options we have?
Also cant we some how automate the BC break testing for this (aka scan
all functions that accept an array with the old API in 5.2, pass it an
ArrayObject instance and see what happens and compare that to 5.3)?
rega
On Wed, Nov 12, 2008 at 10:14 PM, Lukas Kahwe Smith <[EMAIL PROTECTED]>wrote:
> Hi,
>
> here are a few questions that need to be answered ASAP.
>
> If at all possible keep your votes as short as possible. I think all of the
> above topics have been discussed quite a lot on the list. So I hope vote
Lukas Kahwe Smith wrote:
1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC
break will be that "if (extension_loaded('mhash'))" will need fixing if
mhash is removed (answer both)
I) enable ext/hash by default
0
II) remove ext/mhash
0
2) deprecate ereg*. ext/ereg is an ext
23 matches
Mail list logo
