[PHP-DEV] strtr() performance degradation
Hi Gustavo,
I didn't look into the code yet (and really don't like to do it), but we
just noticed terrible performance degradation of strtr() function between
5.4.11 and 5.4.15 coming probably after your changes.
$ cat strtr.php
?php
function foo() {
for ($i = 0; $i 10; $i++) {
strtr(abcdefgh, array(a=11, g=22));
}
}
foo();
$ time sapi/cli/php.5.4.11 strtr.php
real0m0.082s
user0m0.071s
sys0m0.010s
$ time sapi/cli/php.5.4.15 strtr.php
real0m0.594s
user0m0.584s
sys0m0.007s
7 times slower :(
Could you place take a look.
Thanks. Dmitry.
Re: [PHP-DEV] [VOTE] CURLFile uploading API
On Mon, Jan 21, 2013 at 2:32 AM, Stas Malyshev smalys...@sugarcrm.comwrote: Hi! I've started a vote on CURLFile RFC: https://wiki.php.net/rfc/curl-file-upload#vote Please vote. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Hi Stas, I recently gave a presentation on the upcoming php version, and somebody asked why did we introduce an OOP way for this when everything else in ext/curl is procedural. It seems that the OOP aproach was proposed first, and the procedural alternative was added a week later, which seems to be a little bit odd. Is there any particular reason for this? -- Ferenc Kovács @Tyr43l - http://tyrael.hu
[PHP-DEV] Random Monday thought.
Hi.
Recently the setters/getters rfc was declined.
Other than the vote, was there any technical reasons?
I've been sitting here and had a thought.
Currently, if I use ...
?php
class some_base_class {}
?
I can, sort of, think of this as ...
?php
class some_base_class extends \stdClass {}
?
in as much as \stdClass has no constants, properties or methods. In fact,
no behaviour at all.
Now, could it be possible that I could have another PHP maintained base
class or interface that DID support setters/getters?
So, I would have to make the decision at develop time ...
?php
class some_base_class extends \stdClassThatHasSetterGetterSupport {}
?
sort of thing.
So, for classes NOT extending \stdClassThatHasSetterGetterSupport, the
variable/property handling to be used is the original style.
But for those base classes that do extend from
\stdClassThatHasSetterGetterSupport, then these would have property support.
Is this even possible/feasible?
Whilst the vote went against the initial rfc, I'm happy to accept that
(though I wish it had passed as I like the black boxing and the semantic
cleanliness it would provide - IMHO).
To me, if the internals operated as ...
?php
class \stdClassThatHasSetterGetterSupport extends \stdClass {}
?
add if that was enough to enable setters/getters, then COULD this be a way
forward for PHP supporting new functionality without breaking base
functionality?
In essence, turning PHP's internals into a sort of OOP framework.
Regards,
Richard.
--
Richard Quadling
Twitter : @RQuadling
EE : http://e-e.com/M_248814.html
Zend : http://bit.ly/9O8vFY
Re: [PHP-DEV] Random Monday thought.
On Mon, Jun 3, 2013 at 6:49 PM, Richard Quadling rquadl...@gmail.comwrote:
Hi.
Recently the setters/getters rfc was declined.
Other than the vote, was there any technical reasons?
I've been sitting here and had a thought.
Currently, if I use ...
?php
class some_base_class {}
?
I can, sort of, think of this as ...
?php
class some_base_class extends \stdClass {}
?
in as much as \stdClass has no constants, properties or methods. In fact,
no behaviour at all.
Now, could it be possible that I could have another PHP maintained base
class or interface that DID support setters/getters?
So, I would have to make the decision at develop time ...
?php
class some_base_class extends \stdClassThatHasSetterGetterSupport {}
?
sort of thing.
So, for classes NOT extending \stdClassThatHasSetterGetterSupport, the
variable/property handling to be used is the original style.
But for those base classes that do extend from
\stdClassThatHasSetterGetterSupport, then these would have property
support.
Is this even possible/feasible?
Whilst the vote went against the initial rfc, I'm happy to accept that
(though I wish it had passed as I like the black boxing and the semantic
cleanliness it would provide - IMHO).
To me, if the internals operated as ...
?php
class \stdClassThatHasSetterGetterSupport extends \stdClass {}
?
add if that was enough to enable setters/getters, then COULD this be a way
forward for PHP supporting new functionality without breaking base
functionality?
In essence, turning PHP's internals into a sort of OOP framework.
Regards,
Richard.
PHP does not support multiple inheritance. So no, this doesn't solve really
the issue.
Nikita
Re: [PHP-DEV] [VOTE] CURLFile uploading API
Hi! I recently gave a presentation on the upcoming php version, and somebody asked why did we introduce an OOP way for this when everything else in ext/curl is procedural. It needed an object, so it had the object API. Since people also asked for procedural way to create it (no idea why, but they did) I've added that too. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Random Monday thought.
On 3 June 2013 17:55, Nikita Popov nikita@gmail.com wrote:
On Mon, Jun 3, 2013 at 6:49 PM, Richard Quadling rquadl...@gmail.comwrote:
Hi.
Recently the setters/getters rfc was declined.
Other than the vote, was there any technical reasons?
I've been sitting here and had a thought.
Currently, if I use ...
?php
class some_base_class {}
?
I can, sort of, think of this as ...
?php
class some_base_class extends \stdClass {}
?
in as much as \stdClass has no constants, properties or methods. In fact,
no behaviour at all.
Now, could it be possible that I could have another PHP maintained base
class or interface that DID support setters/getters?
So, I would have to make the decision at develop time ...
?php
class some_base_class extends \stdClassThatHasSetterGetterSupport {}
?
sort of thing.
So, for classes NOT extending \stdClassThatHasSetterGetterSupport, the
variable/property handling to be used is the original style.
But for those base classes that do extend from
\stdClassThatHasSetterGetterSupport, then these would have property
support.
Is this even possible/feasible?
Whilst the vote went against the initial rfc, I'm happy to accept that
(though I wish it had passed as I like the black boxing and the semantic
cleanliness it would provide - IMHO).
To me, if the internals operated as ...
?php
class \stdClassThatHasSetterGetterSupport extends \stdClass {}
?
add if that was enough to enable setters/getters, then COULD this be a way
forward for PHP supporting new functionality without breaking base
functionality?
In essence, turning PHP's internals into a sort of OOP framework.
Regards,
Richard.
PHP does not support multiple inheritance. So no, this doesn't solve
really the issue.
Nikita
I'm not talking about multiple inheritance, but of extension.
A new internal PHP base class which internally extends from stdClass, but
is a class that provides additional functionality, specifically
setter/getter logic.
So, from userland, I can not extend and get the current stdClass, or I can
choose \stdClassThatHasSetterGetterSupport and get that.
And if I so wish, I can implement
SomeOtherPHPSuppliedIterfaceLikeIteratorOrWhatever.
Richard.
--
Richard Quadling
Twitter : @RQuadling
EE : http://e-e.com/M_248814.html
Zend : http://bit.ly/9O8vFY
Re: [PHP-DEV] Random Monday thought.
I think the point was that if somebody wants to extend one another class,
maybe one of the SPL classes for example, they can't also extend the base
class with getter/setter support so it's an incomplete solution that will
frustrate many users.
On Mon, Jun 3, 2013 at 2:20 PM, Richard Quadling rquadl...@gmail.comwrote:
On 3 June 2013 17:55, Nikita Popov nikita@gmail.com wrote:
On Mon, Jun 3, 2013 at 6:49 PM, Richard Quadling rquadl...@gmail.com
wrote:
Hi.
Recently the setters/getters rfc was declined.
Other than the vote, was there any technical reasons?
I've been sitting here and had a thought.
Currently, if I use ...
?php
class some_base_class {}
?
I can, sort of, think of this as ...
?php
class some_base_class extends \stdClass {}
?
in as much as \stdClass has no constants, properties or methods. In
fact,
no behaviour at all.
Now, could it be possible that I could have another PHP maintained base
class or interface that DID support setters/getters?
So, I would have to make the decision at develop time ...
?php
class some_base_class extends \stdClassThatHasSetterGetterSupport {}
?
sort of thing.
So, for classes NOT extending \stdClassThatHasSetterGetterSupport, the
variable/property handling to be used is the original style.
But for those base classes that do extend from
\stdClassThatHasSetterGetterSupport, then these would have property
support.
Is this even possible/feasible?
Whilst the vote went against the initial rfc, I'm happy to accept that
(though I wish it had passed as I like the black boxing and the semantic
cleanliness it would provide - IMHO).
To me, if the internals operated as ...
?php
class \stdClassThatHasSetterGetterSupport extends \stdClass {}
?
add if that was enough to enable setters/getters, then COULD this be a
way
forward for PHP supporting new functionality without breaking base
functionality?
In essence, turning PHP's internals into a sort of OOP framework.
Regards,
Richard.
PHP does not support multiple inheritance. So no, this doesn't solve
really the issue.
Nikita
I'm not talking about multiple inheritance, but of extension.
A new internal PHP base class which internally extends from stdClass, but
is a class that provides additional functionality, specifically
setter/getter logic.
So, from userland, I can not extend and get the current stdClass, or I can
choose \stdClassThatHasSetterGetterSupport and get that.
And if I so wish, I can implement
SomeOtherPHPSuppliedIterfaceLikeIteratorOrWhatever.
Richard.
--
Richard Quadling
Twitter : @RQuadling
EE : http://e-e.com/M_248814.html
Zend : http://bit.ly/9O8vFY
--
*Brandon Wamboldt*
Software Engineer
Resume/CV http://brandonwamboldt.com/cv/ - Personal
Site/Bloghttp://brandonwamboldt.ca/
- LinkedIn http://ca.linkedin.com/in/brandonwamboldt - StackOverflow
Careers Profile http://careers.stackoverflow.com/brandonwamboldt - GitHub
Profile https://github.com/brandonwamboldt
Re: [PHP-DEV] Random Monday thought.
Hi Nikita 2013/6/3 Nikita Popov nikita@gmail.com: PHP does not support multiple inheritance. So no, this doesn't solve really the issue. This is also why this makes a lot more sense to implement as an Interface as we can implement more than one per class, much like we do with ArrayAccess. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Random Monday thought.
On 3 June 2013 18:22, Brandon Wamboldt bran...@brandonwamboldt.ca wrote:
I think the point was that if somebody wants to extend one another class,
maybe one of the SPL classes for example, they can't also extend the base
class with getter/setter support so it's an incomplete solution that will
frustrate many users.
On Mon, Jun 3, 2013 at 2:20 PM, Richard Quadling rquadl...@gmail.comwrote:
On 3 June 2013 17:55, Nikita Popov nikita@gmail.com wrote:
On Mon, Jun 3, 2013 at 6:49 PM, Richard Quadling rquadl...@gmail.com
wrote:
Hi.
Recently the setters/getters rfc was declined.
Other than the vote, was there any technical reasons?
I've been sitting here and had a thought.
Currently, if I use ...
?php
class some_base_class {}
?
I can, sort of, think of this as ...
?php
class some_base_class extends \stdClass {}
?
in as much as \stdClass has no constants, properties or methods. In
fact,
no behaviour at all.
Now, could it be possible that I could have another PHP maintained base
class or interface that DID support setters/getters?
So, I would have to make the decision at develop time ...
?php
class some_base_class extends \stdClassThatHasSetterGetterSupport {}
?
sort of thing.
So, for classes NOT extending \stdClassThatHasSetterGetterSupport, the
variable/property handling to be used is the original style.
But for those base classes that do extend from
\stdClassThatHasSetterGetterSupport, then these would have property
support.
Is this even possible/feasible?
Whilst the vote went against the initial rfc, I'm happy to accept that
(though I wish it had passed as I like the black boxing and the
semantic
cleanliness it would provide - IMHO).
To me, if the internals operated as ...
?php
class \stdClassThatHasSetterGetterSupport extends \stdClass {}
?
add if that was enough to enable setters/getters, then COULD this be a
way
forward for PHP supporting new functionality without breaking base
functionality?
In essence, turning PHP's internals into a sort of OOP framework.
Regards,
Richard.
PHP does not support multiple inheritance. So no, this doesn't solve
really the issue.
Nikita
I'm not talking about multiple inheritance, but of extension.
A new internal PHP base class which internally extends from stdClass, but
is a class that provides additional functionality, specifically
setter/getter logic.
So, from userland, I can not extend and get the current stdClass, or I can
choose \stdClassThatHasSetterGetterSupport and get that.
And if I so wish, I can implement
SomeOtherPHPSuppliedIterfaceLikeIteratorOrWhatever.
Richard.
Ah. DOH!
Would having an interface that swapped the default property accessor logic
be any better?
So, I could say ...
?php
class myBase implements \PHPMaintainedSetterGetterLogic {}
?
Hmmm...
I know it is still not perfect.
Shame.
I really would have liked setter/getter.
--
Richard Quadling
Twitter : @RQuadling
EE : http://e-e.com/M_248814.html
Zend : http://bit.ly/9O8vFY
Re: [PHP-DEV] Random Monday thought.
On Mon, Jun 3, 2013 at 10:30 AM, Richard Quadling rquadl...@gmail.comwrote: On 3 June 2013 18:22, Brandon Wamboldt bran...@brandonwamboldt.ca wrote: I think the point was that if somebody wants to extend one another class, maybe one of the SPL classes for example, they can't also extend the base class with getter/setter support so it's an incomplete solution that will frustrate many users. [...] Ah. DOH! Would having an interface that swapped the default property accessor logic be any better? Or a trait (Accessable, Accessored, Accessorable)? Is it possible to have a trait implemented internally? Though it seems that this would still sometimes run afoul of mixing new accessor logic with old.
Re: [PHP-DEV] 5.NEXT Integer and String type modifications
On 2 June 2013 11:11, Johannes Schlüter johan...@schlueters.de wrote: On Jun 2, 2013, at 8:34, Pierre Joye pierre@gmail.com wrote: Obviously there's a pretty significant ABI break here. I propose a tweak of the Z_* macros to fix that. Basically, Z_STRLEN() will cast the result to an int. This is the same behavior as today, and will mean that existing extensions continue to function exactly as today. But new extensions (and elsewhere in core) can use a new macro Z_STRSIZE() which will return the native size_t. A new macro will be a good solution, but I would name it what it actually is, Z_SIZE_T. That's not what it is. It is the length of the string aka. var.value.str.length as such it should indicate its relation to a string. So something like Z_STRSIZE is correct (and the name is nice thinking about Unicode strings where length (characters) != size (bytes)) +1 for the idea +1 for Z_STRSIZE +1 for volunteering, as far as time permits! -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
