Re: [PHP-DEV] quick polls for 5.3
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 extension as of PHP 5.3. Since
ext/ereg is more or less redundant with ext/preg and is likely to not
get much unicode love for PHP 6, the question is if we should mark it
with a E_DEPRECATED in PHP 5.3
+1
3) resource constants (choose one)
a) Should we deprecate constant resources (mostly used to emulate STDIN
and friends)
b) Should we instead just throw an E_STRICT
c) Document as is
c
4) keep ext/phar enabled by default in 5.3?
-1
5) keep ext/sqlite3 enabled by default in 5.3?
-1
6) enable mysqlnd by default in 5.3? (answer both)
I) enable mysqlnd by default
-1
II) also enable ext/mysql, mysqli und pdo_mysql by default since there
will be no external dependencies in this case
-1
Many people do not use MySQL so it should not be enabled by default. This is
even more important if it gets compiled in by default in windows builds.
7) should Output buffering rewrite MFH? this one comes with some
baggage, we need enough people to actually have a look at how things are
in HEAD and make it clear that they will be available for bug fixing and
BC issues resolving. the risk here is obviously that any BC issues will
be hard to isolate for end users.
Am using output buffering but don't know what effect this has.
8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so
either (choose one)
a) revert in HEAD
b) MFH to 5.3
Don't know.
--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] quick polls for 5.3
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 voters
can spare the list needless repetition. Instead if you think that a topic
needs to be discussed, put a short note in your vote under the given topic.
If a number of people also think the topic needs more discussion, then we
can open a new thread dedicated to this topic later this week.
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
0
2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since ext/ereg
is more or less redundant with ext/preg and is likely to not get much
unicode love for PHP 6, the question is if we should mark it with a
E_DEPRECATED in PHP 5.3
+1
3) resource constants (choose one)
a) Should we deprecate constant resources (mostly used to emulate STDIN and
friends)
b) Should we instead just throw an E_STRICT
c) Document as is
0
4) keep ext/phar enabled by default in 5.3?
0
5) keep ext/sqlite3 enabled by default in 5.3?
+1
6) enable mysqlnd by default in 5.3? (answer both)
I) enable mysqlnd by default
II) also enable ext/mysql, mysqli und pdo_mysql by default since there will
be no external dependencies in this case
0
7) should Output buffering rewrite MFH? this one comes with some baggage,
we need enough people to actually have a look at how things are in HEAD and
make it clear that they will be available for bug fixing and BC issues
resolving. the risk here is obviously that any BC issues will be hard to
isolate for end users.
0
8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so
either (choose one)
a) revert in HEAD
b) MFH to 5.3
0
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Best regards,
Konstantin Leboev
Re: [PHP-DEV] quick polls for 5.3
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 an extension as of PHP 5.3. Since
ext/ereg is more or less redundant with ext/preg and is likely to not
get much unicode love for PHP 6, the question is if we should mark it
with a E_DEPRECATED in PHP 5.3
+1
3) resource constants (choose one)
a) Should we deprecate constant resources (mostly used to emulate STDIN
and friends)
b) Should we instead just throw an E_STRICT
c) Document as is
c
4) keep ext/phar enabled by default in 5.3?
-1
5) keep ext/sqlite3 enabled by default in 5.3?
+1
6) enable mysqlnd by default in 5.3? (answer both)
I) enable mysqlnd by default
+1
II) also enable ext/mysql, mysqli und pdo_mysql by default since there
will be no external dependencies in this case
+1
7) should Output buffering rewrite MFH? this one comes with some
baggage, we need enough people to actually have a look at how things are
in HEAD and make it clear that they will be available for bug fixing and
BC issues resolving. the risk here is obviously that any BC issues will
be hard to isolate for end users.
+1
8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so
either (choose one)
a) revert in HEAD
b) MFH to 5.3
a
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Allow unsetting headers previously set usingheader()
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 informations on the change can be found in the commit message:
http://news.php.net/php.cvs/54228
Regards,
Arnaud
On Sunday 09 November 2008 22:49:47 Uwe Schindler wrote:
+1
I have no problem with implementing this for NSAPI after the patch is
committed to CVS, just keep me informed about this.
-
Uwe Schindler
[EMAIL PROTECTED] - http://www.php.net
NSAPI SAPI developer
Bremen, Germany
-Original Message-
From: Arnaud LB [mailto:[EMAIL PROTECTED] On Behalf Of Arnaud Le Blanc
Sent: Sunday, November 09, 2008 10:02 PM
To: internals@lists.php.net
Cc: Christian Schmidt
Subject: Re: [PHP-DEV] [PATCH] Allow unsetting headers previously set
usingheader()
On Sunday 09 November 2008 19:51:31 Christian Schmidt wrote:
Stan Vassilev | FM wrote:
I suggest header_remove('*') or simply header_remove() /no param/
removes all headers (including the one PHP sets by default), so we can
start with a clear state.
I added header_remove('Foo'). header_remove() without arguments removes
all headers (though Apache still adds some headers that you cannot
remove).
I have tested with apache2handler and cgi. I had to change the signature
of SAPI header_handler function and sapi_header_struct, so the other
SAPIs should be updated for this. I am not sure how to test all these?
Creating a testing environment for all those webservers seems like a
huge task.
I am not comfortable with the size of this patch, given my understanding
of the PHP source code and my general C skills, so I am posting this
patch hoping that somebody will pick it up or help me get it into shape.
It looks good. The signature change is not that bad if it forces all SAPIs
to
be updated and ensures that PHP behaves the same way with all SAPIs.
It is also possible to add something like header_delete_handler() or
header_handler_ex() to sapi_module_struct if the signature change is to be
avoided.
Regards,
Arnaud
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] array_key_exists BC break
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)? regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] quick polls for 5.3
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) c 4) keep ext/phar enabled by default in 5.3? +1 5) keep ext/sqlite3 enabled by default in 5.3? 0 6) enable mysqlnd by default in 5.3? (answer both) -1 both: would favor mysql by including client in default installation 7) should Output buffering rewrite MFH? this one comes with some 8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so 0 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: quick polls for 5.3
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/ereg is an extension as of PHP 5.3. Since
ext/ereg is more or less redundant with ext/preg and is likely to not
get much unicode love for PHP 6, the question is if we should mark it
with a E_DEPRECATED in PHP 5.3
+1
3) resource constants (choose one)
a) Should we deprecate constant resources (mostly used to emulate STDIN
and friends)
b) Should we instead just throw an E_STRICT
c) Document as is
c
4) keep ext/phar enabled by default in 5.3?
+1
5) keep ext/sqlite3 enabled by default in 5.3?
+1
6) enable mysqlnd by default in 5.3? (answer both)
I) enable mysqlnd by default
II) also enable ext/mysql, mysqli und pdo_mysql by default since there
will be no external dependencies in this case
+0 for both
7) should Output buffering rewrite MFH? this one comes with some
baggage, we need enough people to actually have a look at how things are
in HEAD and make it clear that they will be available for bug fixing and
BC issues resolving. the risk here is obviously that any BC issues will
be hard to isolate for end users.
abstain
8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so
either (choose one)
a) revert in HEAD
b) MFH to 5.3
abstain
Regards,
Karsten
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] quick polls for 5.3
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) remove ext/mhash
+1
2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since ext/ereg
is more or less redundant with ext/preg and is likely to not get much
unicode love for PHP 6, the question is if we should mark it with a
E_DEPRECATED in PHP 5.3
+1
3) resource constants (choose one)
a) Should we deprecate constant resources (mostly used to emulate STDIN and
friends)
b) Should we instead just throw an E_STRICT
c) Document as is
c
4) keep ext/phar enabled by default in 5.3?
+1
5) keep ext/sqlite3 enabled by default in 5.3?
+1
6) enable mysqlnd by default in 5.3? (answer both)
I) enable mysqlnd by default
+1
II) also enable ext/mysql, mysqli und pdo_mysql by default since there will
be no external dependencies in this case
-1
7) should Output buffering rewrite MFH? this one comes with some baggage, we
need enough people to actually have a look at how things are in HEAD and
make it clear that they will be available for bug fixing and BC issues
resolving. the risk here is obviously that any BC issues will be hard to
isolate for end users.
+0
8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so
either (choose one)
a) revert in HEAD
b) MFH to 5.3
b
--
Alexey Zakhlestin
http://blog.milkfarmsoft.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] How to submit a patch for SOAP extension?
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/unsub.php
Re: [PHP-DEV] How to submit a patch for SOAP extension?
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 patch in the bug itself is the best way to do not loose it. A small notice to internals may help too :) -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Traits,Grafts, horizontal reuse
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 code can break another entities code. The
great thing about Grafts is that the implementation is not mixed. Grafts
are completely independent entities with their own state. I think in
many cases where inheritance or traits seem tempting, complete
encapsulation is actually the cleaner solution.
The Grafts proposal, however, suffered a little from being born out of
traits, I think. Something similar to Grafts is already possible in
current php, but it is not very beautiful. If we start from there
however, Grafts could become very helpful syntactic sugar. Let's look at
current PHP first:
class Counter {
private $cnt = 0;
public function inc() {
$this-cnt++;
}
public function reset() {
$this-cnt = -1;
$this-inc();
}
}
class TakeANumberForTheQueue{
, so this is one , but I think it could be even better when it was much
closer to current PHP than suggested in the RFC. Let me explain what I
mean. Graft were born out of the idea of traits. Traits are a variant of
inheritance and a trade-off between single and multiple inheritance with
the goal to reduce code duplication. The problem with inheritance is
that code can break because code from different classes (or traits) is
mixed together
interfering with Either kind of inheritance can be very tempting to be
used to reuse functionality.
implement code reuse. Code reuse is tempting but often enough it is not
really necessary to reuse the
comes from the wrong direction and didn't go far enough.
Traits conquer the lacks of single inheritance without giving the full
power of multiple inheritance. Traits are still sort of inheritance.
When a class uses a trait the trait's code can access class
implementation details and vice-vera. This might come in handy at some
point, however I personally lack a good use case for now. Can somebody
provide a sensible use case for traits?
A Problem with code inheritance (single, traits, whatever) is that the
possibility to use inheritance seduces to use it even when it is not
necessarily needed. Stefan's Counter example is a good one.
What I find even more promising than Traits are Grafts.
I know Grafts where born out of the traits idea, but I want to try to
put them idea a little forward and separate the from the traits idea
even stronger than Stefan already did.
Why do we want Grafts?
Because inheritance can be a problem
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] gnaaa. Hit the submit button too early.
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
[PHP-DEV] Grafts, Traits, horizontal reuse
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 code can break another entities code. The
great thing about Grafts is that the implementation is not mixed. Grafts
are completely encapsulated entities with their own state. I think in
many cases where inheritance or traits seem tempting, complete
encapsulation is actually the cleaner solution.
The Grafts proposal, however, suffered a little from being born out of
traits, I think. Something similar to Grafts is already possible in
current php, but it is not very beautiful. If we start from there
however, Grafts could become very helpful syntactic sugar. Let's look at
current PHP first:
class Counter {
private $cnt = 0;
public function inc() {
$this-cnt++;
return $this;
}
public function reset() {
$this-cnt = -1;
$this-inc();
return $this;
}
public function current(){
return $this-cnt;
return $this;
}
}
class QueueTicketPrinter{
private $counter;
public __construct(){
$this-counter = new Counter();
}
public function takeNumber(){
print 'your number is .$this-counter-current();
$this-counter-inc();
}
public function current(){
$this-counter-current();
}
public function reset(){
$this-counter-reset();
}
}
This is a lot of code in QueueTicketPrinter for that it mostly reuses
Counter. Grafts as syntactic sugar could make it look as short as:
class QueueTicketPrinter{
use Counter as private $counter{
public current();
public reset();
}
public function takeNumber(){
print 'your number is .$this-counter-current();
$this-counter-inc();
}
}
However a problem remains. The methods of counter return $this (aka
implement a fluent interface). One idea that came to my mind to solve
this problem: PHP could provide a keyword fluent that replaces a methods
return value to form a fluent interface i.e. return $this:
class QueueTicketPrinter{
use Counter as private $counter{
public fluent current();
public fluent reset();
}
public function takeNumber(){
print 'your number is .$this-counter-current();
$this-counter-inc();
}
}
The keyword fluent ignores whatever value the Counter function may
return and returns an the instance of QueueTicketPrinter instead.
Finally, can somebody provide a sensible use case for traits, that
cannot be solved with Grafts? I am sure there is, but I am currently
lacking one.
Cheers
Christopher
P.S. Hope that stupid post before does not make me seem too much like it ;).
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] array_key_exists BC break
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 use new API with 'a' parameter, which accepts only arrays proper. The proposal is to have some new parameter - say 'a%' - which would call HASH_OF on objects where it makes sense. The definition of makes sense is not clear yet, since, for example, sort() on some objects may make sense - if the object's get_properties returns real storage - or may not, if that handler returns the mere copy of the real data. We might use some interface as a marker - like ArrayAccess - though I'm not sure if it will work in all circumstances. 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 parameters in 5.3 and comparing how they react to arrays in 5.2 and in 5.3. Some of them, btw, might accept objects even though it doesn't make much sense - as above. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] array_key_exists BC break
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 parameters in 5.3 and comparing how they react to arrays in 5.2 and in 5.3. Some of them, btw, might accept objects even though it doesn't make much sense - as above. 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. S -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] array_key_exists BC break
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 function - you get zval** and do whatever you want. We could convert them to use 'z' and then parse it into arrays but I think that would be cheating. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ReflectionProperty::setValue() and ReflectionProperty::setAccessible()
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 Wednesday, November 12, 2008, 8:29:05 PM, you wrote: Currently ReflectionProperty::setValue() ignores the setting made by ReflectionProperty::setAccessible(). Is this intentional or was it just forgotten to handle ref-ignore_visibility in setValue()? For some code I am working on it would be really helpful if setValue() could optionally work with private and protected attributes. -- Sebastian Bergmann http://sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69 Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] quick polls for 5.3
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 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 an extension as of PHP 5.3. Since ext/ereg
is more or less redundant with ext/preg and is likely to not get much
unicode love for PHP 6, the question is if we should mark it with a
E_DEPRECATED in PHP 5.3
+1
3) resource constants (choose one)
a) Should we deprecate constant resources (mostly used to emulate STDIN and
friends)
b) Should we instead just throw an E_STRICT
c) Document as is
c
C is ok
4) keep ext/phar enabled by default in 5.3?
Strongly +1
5) keep ext/sqlite3 enabled by default in 5.3?
0
6) enable mysqlnd by default in 5.3? (answer both)
I) enable mysqlnd by default
-1
II) also enable ext/mysql, mysqli und pdo_mysql by default since there will
be no external dependencies in this case
-1
7) should Output buffering rewrite MFH? this one comes with some baggage, we
need enough people to actually have a look at how things are in HEAD and
make it clear that they will be available for bug fixing and BC issues
resolving. the risk here is obviously that any BC issues will be hard to
isolate for end users.
+1
8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so
either (choose one)
a) revert in HEAD
b) MFH to 5.3
0
--
Alexey Zakhlestin
http://blog.milkfarmsoft.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Guilherme Blanco - Web Developer
CBC - Certified Bindows Consultant
Cell Phone: +55 (16) 9166-6902
MSN: [EMAIL PROTECTED]
URL: http://blog.bisna.com
Rio de Janeiro - RJ/Brazil
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ReflectionProperty::setValue() and ReflectionProperty::setAccessible()
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 not setValue() when do not actually need it for getValue() [1]. -- [1] http://www.derickrethans.nl/private_properties_exposed.php -- Sebastian Bergmann http://sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error_log - sapi.log_message
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 logging channel, since presently there's no reliable way to access it without resetting error_log. Any objection? -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] quick polls for 5.3
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 spare the list needless repetition. Instead if you
think that a topic needs to be discussed, put a short note in your
vote under the given topic. If a number of people also think the topic
needs more discussion, then we can open a new thread dedicated to this
topic later this week.
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 an extension as of PHP 5.3. Since ext/
ereg is more or less redundant with ext/preg and is likely to not get
much unicode love for PHP 6, the question is if we should mark it with
a E_DEPRECATED in PHP 5.3
+1
3) resource constants (choose one)
a) Should we deprecate constant resources (mostly used to emulate
STDIN and friends)
b) Should we instead just throw an E_STRICT
c) Document as is
c
4) keep ext/phar enabled by default in 5.3?
+1
5) keep ext/sqlite3 enabled by default in 5.3?
+1
6) enable mysqlnd by default in 5.3? (answer both)
I) enable mysqlnd by default
II) also enable ext/mysql, mysqli und pdo_mysql by default since there
will be no external dependencies in this case
+0
7) should Output buffering rewrite MFH? this one comes with some
baggage, we need enough people to actually have a look at how things
are in HEAD and make it clear that they will be available for bug
fixing and BC issues resolving. the risk here is obviously that any BC
issues will be hard to isolate for end users.
+1
8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so
either (choose one)
a) revert in HEAD
b) MFH to 5.3
+1
In short, MFH what we can, keep at least one DB in PHP per default.
Enable all by default that does not depend on any library or move to
PECL. Introduce stuff to core, enabled by default that we develop for
mainstream usage. Do not do unneccessary changes, clarify docs always.
And last but not least adhere to KISS and consistency.
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PECL-CVS] cvs: pecl /sphinx sphinx.c
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 go by in the last couple of days. If it's not too late, I would suggest that the change to put static into the macro be reverted because it is causing needless changes to fan out into other modules. Additionally, it is also not possible to put those things in external C source files if they're always implicitly static. Just my 2 cents. --Wez. -- Regards, Felipe Pena -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] Using cc as the default compiler
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 install another C compiler and make them their default compiler by putting the necessary path to cc first, they would like to use cc instead of gcc. Maybe I'm wrong in that point, but I consider 'cc' as the default C compiler on a system. We also have the checks for both ICC and SunCC in our buildsystem and they are handled well. Therefore I would suggest that we are checking for the cc binary by default and than fallback to gcc. I'm aware that people usually should use gcc as their default compiler, but if you specifically installed another compiler you might have good reasons to use it (because of the used architecture, or because you like to use software you bought). The implementation is straight forward as the AC_PROG_CC macro supports this (http://www.gnu.org/software/libtool/manual/autoconf/C-Compiler.html): Index: b/configure.in === --- a/configure.in 2008-11-07 00:28:53.047697316 +0100 +++ b/configure.in 2008-11-11 00:19:08.794287603 +0100 @@ -140,7 +140,7 @@ dnl Checks for programs. dnl - -AC_PROG_CC +AC_PROG_CC([cc]) PHP_DETECT_ICC PHP_DETECT_SUNCC AC_PROG_CC_C_O If there are no objections on this, I would like to commit this fix to 5.3 and 6.0. Regards David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
