[PHP-DEV] [PATCH] unregister_shutdown_function()
Hi, This patch implements unregister_shutdown_function(), which removes a function already registered with register_shutdown_function(). It resolves request #53702 (according to google, not sure if it's still active) and I've thought it a curious absence for a while. The patch (against trunk) is at: http://spellign.com/patches/php-trunk-unregister_shutdown_function.patch N.B. I don't return from the apply func with ZEND_HASH_APPLY_STOP when it matches because it's also possible to register the same function twice (maybe a bug?) Regards, Arpad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Object oriented session handlers
On 20 June 2011 01:39, Arpad Ray array...@gmail.com wrote:
On Mon, Jun 6, 2011 at 5:31 PM, Richard Quadling rquadl...@gmail.com wrote:
Not an internals expert, but I do have a question.
When would the session handler object be destroyed?
If sessions are being logged to a DB (maybe via a userland PHP class),
is internal reference counting enough to handle the order of
destruction?
If the DB connection is destroyed before the session handler gets it
destructor called (or the session_write_close equivalent), the session
won't be able to log the data and there would be no warning to the
client as engine is in auto tidy up mode.
Hi,
Many thanks for your question, because I hadn't given the matter much
thought. The current patch (#7) uses static methods so it doesn't
change the status quo - the user would need still need to manually
close the session (or register a shutdown function) in order to use an
object in the close() method.
I've spent some time thinking about this and I think we have a couple
of options. First of all I've changed the interface so that the
methods are no longer static, it would already accept an object before
but it would just use it find the class name, and call the methods
statically. Now it only accepts an object.
The two options I've implemented are:
Destructor in the SessionHandler class:
http://spellign.com/patches/php-trunk-session-oo8-destruct.patch
This works ok with some provisions:
- The user's SessionHandler class must hold on to any objects it will
need in close(), (in a property, presumably). While it's possible that
the session handler would still get destructed afterwards, this is the
only way to ensure it.
- If the user overrides __destruct(), they must call parent::__destruct().
Automatically register a shutdown function:
http://spellign.com/patches/php-trunk-session-oo8-shutdown_function.patch
The only argument I can think of against it is that it's possible the
user might, out of habit, register their own shutdown function *after*
calling session_set_save_handler(). In that case their shutdown
function would find the session already closed.
Obviously, if the developer takes care and calls the destructors in
the right order, then everything will be OK, but this is not something
I see very often.
What about circular references and interdependent references?
This would give the destructor option some trouble - in this case
instances are destructed in the order in which they were created, and
it seems likely that the DB object from your example would be created
first.
I prefer the shutdown function option. We could even ensure that the
user's shutdown function always gets called first by adding a separate
hash of internal shutdown functions, however I think that would
overcomplicate matters for something we can clearly document.
The option I haven't mentioned is to preserve the status quo, I think
that would be a pity since we have the chance to address it while
keeping BC now.
I've moved the tests into a separate patch so the above differences are
clearer:
http://spellign.com/patches/php-trunk-session-oo8-tests.patch
Regards,
Arpad
Thanks for looking into this a lot more.
I've always used a First-In-Last-Out (FILO) creation/destruction order
and incorporated the concept of ownership.
Any time an instance of a class is created, it has to be owned by
another instance (of any type) or by a pseudo top-parent. In my case,
I always have an instance of tApp, to which I attach my DB resource
container (invariable I communicate with multiple unlink DB servers)
and a session class (old skool).
tApp is created, DB(s) are linked to. Session is started.
As part of the app destructor, the session is closed first. Always.
Then the DB connectors. For me, during the shutdown of tApp, there is
no more activity to be processed, so the cleanup can take place in a
controlled manner. And the reverse order seems the best way.
And I always call the destructor on tApp as part of my code. A
try{}finally{} clause would certainly be beneficial but probably not
essential.
Hopefully, by the time my script has finished, all resources are
closed and finalised and the script engine shutdown/cleanup cycle is
doing nothing.
Essentially, it is moving the cleanup process into the hands of the
developer. If they don't control the order, I'm not sure you can
predict the order. Or if it can be predicted, it may not be the
desired order.
I think this is a great addition to PHP. I think it needs to be
PHP\SessionHandler. I think all new classes should be namespaced to
PHP, but that's another topic I'm sure.
--
Richard Quadling
Twitter : EE : Zend : PHPDoc
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Standard constants as part of the lexer
The constants true, false and null are used very often. Unfortunately, every usage of either of these constants invokes a constant lookup. There is no problem with this, constant lookups are fast, but I nevertheless implemented these constants directly in the lexer to avoid these lookups. I'd be glad to see this change in 5.4 as the performance enhancement would be a steal. I've also added a new OP code to hard-code count() and strlen() which improves the performance by ~800%. This is nice, but limits the usage of count() and strlen() as method name - if no further changes will be made at the parser. I would rather see a optimization for every function call in 5.4.x. I'll take a look at this soon, maybe I can provide a patch for this, too. What do you think about the constants optimization? Unfortunateley, I've broken the power cable of my macbook and have to wait for a new one. I'll deliver in addition the patch if you like the idea. Robert
[PHP-DEV] Optimized smart strings
PHP makes use of the smart string library. I've optimized the smart_str_append_long() macro in order to save one division per cycle. At the moment one modulo and one division is used. The optimized version uses one division (which gets optimized away in most situations) and one additional multiplication + subtraction. I've additionally added also a new maco called smart_str_append_const(). This macro is used to append constant strings with a sizeof()-1 instead of strlen() call. I'd be glad to see this change in 5.4. As I wrote in the earlier post, I'll deliver the patch in addition. PS: yes, this is a really small micro optimization. Robert
Re: [PHP-DEV] Standard constants as part of the lexer
On Mon, 20 Jun 2011, Robert Eisele wrote:
The constants true, false and null are used very often. Unfortunately,
every usage of either of these constants invokes a constant lookup.
There is no problem with this, constant lookups are fast, but I
nevertheless implemented these constants directly in the lexer to
avoid these lookups. I'd be glad to see this change in 5.4 as the
performance enhancement would be a steal.
Would that not break the following code?:
?php
class bar
{
function true()
{
return true;
}
}
$A = new bar;
$A-true();
?
I've also added a new OP code to hard-code count() and strlen() which
improves the performance by ~800%. This is nice, but limits the usage
of count() and strlen() as method name - if no further changes will be
made at the parser. I would rather see a optimization for every
function call in 5.4.x. I'll take a look at this soon, maybe I can
provide a patch for this, too.
Although it's a nice performance increase, I think that breaking
count() as a method name is not a good idea, as I would assume it's
used a lot. Even though count() and strlen() can be optimised that much,
how much does it buy a fully fledged application?
Then there is also the deliberation on whether it's good to go this
general direction, because I am sure we can make a case to convert every
function into an opcode perhaps.
cheers,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Optimized smart strings
On Mon, 20 Jun 2011, Robert Eisele wrote: PHP makes use of the smart string library. I've optimized the smart_str_append_long() macro in order to save one division per cycle. At the moment one modulo and one division is used. The optimized version uses one division (which gets optimized away in most situations) and one additional multiplication + subtraction. I've additionally added also a new maco called smart_str_append_const(). This macro is used to append constant strings with a sizeof()-1 instead of strlen() call. I'd be glad to see this change in 5.4. As I wrote in the earlier post, I'll deliver the patch in addition. PS: yes, this is a really small micro optimization. It is, but it is not going to break anything, so IMO a good idea to add. It would be awesome if we could document the whole smart_string API as well though; even though it's fairly simple, moar documentation is good! cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Standard constants as part of the lexer
Am 20.06.2011 13:00, schrieb Derick Rethans: Although it's a nice performance increase, I think that breaking count() as a method name is not a good idea, as I would assume it's used a lot. Even though count() and strlen() can be optimised that much, how much does it buy a fully fledged application? Especially since we have a built-in Countable interface that requires the implementation of a count() method. -- Sebastian BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Standard constants as part of the lexer
2011/6/20 Derick Rethans der...@php.net
On Mon, 20 Jun 2011, Robert Eisele wrote:
The constants true, false and null are used very often. Unfortunately,
every usage of either of these constants invokes a constant lookup.
There is no problem with this, constant lookups are fast, but I
nevertheless implemented these constants directly in the lexer to
avoid these lookups. I'd be glad to see this change in 5.4 as the
performance enhancement would be a steal.
Would that not break the following code?:
?php
class bar
{
function true()
{
return true;
}
}
$A = new bar;
$A-true();
?
Yes, indeed. But as I wrote, we could add T_SIZEOF (symbol for count +
strlen) and T_LVAL (used for constants) as exception for method and function
names. A more general solution would be better, instead of hacking such
things without deep considerations in an official tree.
I've also added a new OP code to hard-code count() and strlen() which
improves the performance by ~800%. This is nice, but limits the usage
of count() and strlen() as method name - if no further changes will be
made at the parser. I would rather see a optimization for every
function call in 5.4.x. I'll take a look at this soon, maybe I can
provide a patch for this, too.
Although it's a nice performance increase, I think that breaking
count() as a method name is not a good idea, as I would assume it's
used a lot. Even though count() and strlen() can be optimised that much,
how much does it buy a fully fledged application?
I think it depends on the experience of the developers. There are many -
halfway ugly - PHP optimization tricks on the net. If these are used, the
difference wouldn't that much. But constructs like for($i=0; $istrlen($x);
$i++) could get optimized vigorous.
Then there is also the deliberation on whether it's good to go this
general direction, because I am sure we can make a case to convert every
function into an opcode perhaps.
This would make extension development much more complicated.
cheers,
Derick
grz Robert
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
[PHP-DEV] Changed behaviour for strtr()
Here is the next one. I think it's quite intuitive to use strtr() to remove single characters of a string, too, instead of using many str_replace($str, $chr, ). I'd glad to see this change also in 5.4. Additionally, I've removed the lookup-table generation as gcc doesn't optimize this away. Robert
Re: [PHP-DEV] Changed behaviour for strtr()
On Mon, 20 Jun 2011, Robert Eisele wrote: Here is the next one. I think it's quite intuitive to use strtr() to remove single characters of a string, too, instead of using many str_replace($str, $chr, ). I'd glad to see this change also in 5.4. Do you mean that (the currently documented): If from and to have different lengths, the extra characters in the longer of the two are ignored. The length of str will be the same as the return value's. would then change into: If from and to have different lengths, the extra characters in the longer of the two are assumed to be the empty string, thus removing those characters. The length of str will be the same as the return value's unless the from and to have a different length. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] foreach() for strings
foreach() has many functions, looping over arrays, objects and implementing the iterator interface. I think it's also quite intuitive to use foreach() for strings, too. If you want to implement a parser in PHP, you have to go the way with for + strlen + substr() or $x[$i] to address one character of the string. We could overdo the functionality of foreach() by implementing LVAL's, too, in order to access single bits but this is really uncommon, even if the way of thinking could be, that foreach() gives a single attribute of each value, no matter if it's a complex object with the iterator interface or a primitive. What do you think about this one? My point of view is, that foreach() is very useful, which was acknowledged by many ppl via the comments of my article. I think, adding features like this persuades the one or the other PHP user to upgrade to 5.4. Robert
Re: [PHP-DEV] [PATCH] unregister_shutdown_function()
On Mon, 2011-06-20 at 07:36 +0100, Arpad Ray wrote:
This patch implements unregister_shutdown_function(), which removes a
function already registered with register_shutdown_function().
It resolves request #53702 (according to google, not sure if it's
still active) and I've thought it a curious absence for a while.
Why do you register a shutdown function if you want to remove it again?
Shouldn't you fix the architecture of your code instead of relying on
such functions?
The patch (against trunk) is at:
http://spellign.com/patches/php-trunk-unregister_shutdown_function.patch
Does register_shutdown_function() work with closures? (Didn't test it)
Then the following should work, too, which isn't the case in your code:
$a = function() {};
register_shutdown_function($a);
unregister_shutdown_function($a);
I also think once that functionality is there the next request will be
get_registered_shutdown_functions()
or something along the lines.
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] 5.4 features for vote (long)
On Thu, 16 Jun 2011, Stas Malyshev wrote:
3. Add E_STRICT to E_ALL. Nuff said. We did it in 6.0/unicode branch but
didn't backport it.
Not sure about that. Can't we just tell people to use -1 ?
6. Array shortcuts. Make [ 'blah', 'blah' ] work same as array('blah',
'blah'), etc. Does not include any new JSON-like syntax, etc. - just making
'[' be 'array(' and ']' be ')' in that context.
And for associative arrays only = ?
8. Cli web server. Built-in mini-HTTP server run directly from PHP binary.
Assigned: Moriyoshi Koizumi
I'd really like to see that one. I thought the patch was already
committed?
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] foreach() for strings
On Mon, 20 Jun 2011, Robert Eisele wrote: foreach() has many functions, looping over arrays, objects and implementing the iterator interface. I think it's also quite intuitive to use foreach() for strings, too. If you want to implement a parser in PHP, you have to go the way with for + strlen + substr() or $x[$i] to address one character of the string. Yes, this sounds like a good addition to me. One question though, what to do with an object that implements __toString() ? We could overdo the functionality of foreach() by implementing LVAL's, too, in order to access single bits but this is really uncommon, even if the way of thinking could be, that foreach() gives a single attribute of each value, no matter if it's a complex object with the iterator interface or a primitive. What do you think about this one? My point of view is, that foreach() is very useful, which was acknowledged by many ppl via the comments of my article. I don't think we should do it for bits, as nothing in PHP really does do anything with that. If you want to do stuff with bits, I think the bitset package (http://pecl.php.net/package/Bitset) is the way forwards. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] foreach() for strings
2011/6/20 Derick Rethans der...@php.net On Mon, 20 Jun 2011, Robert Eisele wrote: foreach() has many functions, looping over arrays, objects and implementing the iterator interface. I think it's also quite intuitive to use foreach() for strings, too. If you want to implement a parser in PHP, you have to go the way with for + strlen + substr() or $x[$i] to address one character of the string. Yes, this sounds like a good addition to me. One question though, what to do with an object that implements __toString() ? That's the question, maybe one must force __toString() via an explicit string-cast: foreach( (string) $obj as $k=$v) We could overdo the functionality of foreach() by implementing LVAL's, too, in order to access single bits but this is really uncommon, even if the way of thinking could be, that foreach() gives a single attribute of each value, no matter if it's a complex object with the iterator interface or a primitive. What do you think about this one? My point of view is, that foreach() is very useful, which was acknowledged by many ppl via the comments of my article. I don't think we should do it for bits, as nothing in PHP really does do anything with that. If you want to do stuff with bits, I think the bitset package (http://pecl.php.net/package/Bitset) is the way forwards. yep, i totally agree. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug
Re: [PHP-DEV] foreach() for strings
On Mon, 2011-06-20 at 13:27 +0200, Robert Eisele wrote: foreach() has many functions, looping over arrays, objects and implementing the iterator interface. I think it's also quite intuitive to use foreach() for strings, too. I would prefer a TextIterator as we had in the old PHP 6 as this allows more powerful filtering etc. using iterator semantics even though this might be a bit slower. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Negative string offsets
Negative string offsets is a wish and also an implementation of my running PHP version for long. It operates in the same fashion like substr() with negative offsets, but avoids the function call and is much smarter if one single character has to be extracted: $str = Hallo; $str[0] == H $str[-1] == o; If -6 is used as offset, the old warning is displayed because it's the first undefined negative offset. The same thing for setting: $str[-1] = '0'; $str[-4] = 4; will result in H4ll0 Would be glad to see this in 5.4 Robert
Re: [PHP-DEV] Negative string offsets
On Mon, 20 Jun 2011, Robert Eisele wrote: Negative string offsets is a wish and also an implementation of my running PHP version for long. It operates in the same fashion like substr() with negative offsets, but avoids the function call and is much smarter if one single character has to be extracted: $str = Hallo; $str[0] == H $str[-1] == o; If -6 is used as offset, the old warning is displayed because it's the first undefined negative offset. The same thing for setting: $str[-1] = '0'; $str[-4] = 4; will result in H4ll0 Would be glad to see this in 5.4 Sounds like a good addition to me! For ArrayAccess, would this calculate the correct index so that current implementations of ArrayAccess don't have to be changed? cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] foreach() for strings
On Mon, 20 Jun 2011, Johannes Schlüter wrote: On Mon, 2011-06-20 at 13:27 +0200, Robert Eisele wrote: foreach() has many functions, looping over arrays, objects and implementing the iterator interface. I think it's also quite intuitive to use foreach() for strings, too. I would prefer a TextIterator as we had in the old PHP 6 as this allows more powerful filtering etc. using iterator semantics even though this might be a bit slower. I think TextIterator is another good addition, but it will make PHP depend on ICU. Therefore, I think just a foreach for strings seems valuable to me. Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] foreach() for strings
On Mon, 20 Jun 2011, Robert Eisele wrote: 2011/6/20 Derick Rethans der...@php.net On Mon, 20 Jun 2011, Robert Eisele wrote: foreach() has many functions, looping over arrays, objects and implementing the iterator interface. I think it's also quite intuitive to use foreach() for strings, too. If you want to implement a parser in PHP, you have to go the way with for + strlen + substr() or $x[$i] to address one character of the string. Yes, this sounds like a good addition to me. One question though, what to do with an object that implements __toString() ? That's the question, maybe one must force __toString() via an explicit string-cast: foreach( (string) $obj as $k=$v) That's a sensible thing indeed. We just need to make sure we document this with an example and a test then. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Negative string offsets
Hi, 2011/6/20 Robert Eisele rob...@xarg.org Negative string offsets is a wish and also an implementation of my running PHP version for long. It operates in the same fashion like substr() with negative offsets, but avoids the function call and is much smarter if one single character has to be extracted: $str = Hallo; $str[0] == H $str[-1] == o; If -6 is used as offset, the old warning is displayed because it's the first undefined negative offset. The same thing for setting: $str[-1] = '0'; $str[-4] = 4; will result in H4ll0 Would be glad to see this in 5.4 Robert I like this one, +1. -- Regards, Felipe Pena
[PHP-DEV] [VOTE] voting rfc
Hi Internals, we have been working on getting an rfc together on how to deal with votes on rfcs. We aim to provide a simple mechaism for votes while still maintaining freedom on how to do votes and how to work on rfcs. I want to move forward on the voting and release RFCs, so we can move forward on the 5.4 process. Therefore I call for votes on the voting RFC. The RFC can be found here: https://wiki.php.net/rfc/voting You can vote here: https://wiki.php.net/rfc/voting/vote Votes are open until Monday 27.06.2011. Thank you David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] foreach() for strings
2011/6/20 Johannes Schlüter johan...@schlueters.de: On Mon, 2011-06-20 at 13:27 +0200, Robert Eisele wrote: foreach() has many functions, looping over arrays, objects and implementing the iterator interface. I think it's also quite intuitive to use foreach() for strings, too. I would prefer a TextIterator as we had in the old PHP 6 as this allows more powerful filtering etc. using iterator semantics even though this might be a bit slower. A foreach with string should be seen as binary buffer, with no clue about its content and only to fetch it byte by byte. TextIterator can be smarter and support unicode when ICU is available. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] foreach() for strings
hi Robert, I would go with a RFC for that one, at least to document/cover edge cases to help the doc team to properly document this change if it gets approved. Thanks for your work so far! On Mon, Jun 20, 2011 at 1:27 PM, Robert Eisele rob...@xarg.org wrote: foreach() has many functions, looping over arrays, objects and implementing the iterator interface. I think it's also quite intuitive to use foreach() for strings, too. If you want to implement a parser in PHP, you have to go the way with for + strlen + substr() or $x[$i] to address one character of the string. We could overdo the functionality of foreach() by implementing LVAL's, too, in order to access single bits but this is really uncommon, even if the way of thinking could be, that foreach() gives a single attribute of each value, no matter if it's a complex object with the iterator interface or a primitive. What do you think about this one? My point of view is, that foreach() is very useful, which was acknowledged by many ppl via the comments of my article. I think, adding features like this persuades the one or the other PHP user to upgrade to 5.4. Robert -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] 5.4 features for vote (long)
On Mon, Jun 20, 2011 at 8:39 PM, Derick Rethans der...@php.net wrote: 8. Cli web server. Built-in mini-HTTP server run directly from PHP binary. Assigned: Moriyoshi Koizumi I'd really like to see that one. I thought the patch was already committed? Not yet. I'm gonna commit it in six hours or so if no one objects ;-) Moriyoshi Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- 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
[PHP-DEV] [VOTE] release process RFC
Hi Internals, We have been working on getting this rfc on how to have clear and transparent releases process, release cycles and how and which features get into a release. The RFC is finally ready for the votes. Therefore we call for votes on the release process RFC. The RFC can be found here: https://wiki.php.net/rfc/releaseprocess You can vote here: https://wiki.php.net/rfc/releaseprocess/vote Votes are open until Monday 27.06.2011. Thank you, -- Pierre @pierrejoye | http://blog.thepimp.net | http://libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Can't vote yet, as RFC has options (Was: Re: [PHP-DEV] [VOTE] release process RFC)
On Mon, 20 Jun 2011, Pierre Joye wrote: Hi Internals, We have been working on getting this rfc on how to have clear and transparent releases process, release cycles and how and which features get into a release. The RFC is finally ready for the votes. Therefore we call for votes on the release process RFC. The RFC can be found here: https://wiki.php.net/rfc/releaseprocess You can vote here: https://wiki.php.net/rfc/releaseprocess/vote In this RFC, there is still the options for both one major and multiple major versions at the same time. I don't think you can vote on something that is unclear. I therefore voted -1. I am not generally against this RFC, but this point needs to be discussed first IMO. As having 5 active branches at the same time for the multiple major releases option is *not* workable. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP patches
Could I please get an wiki account? I've posted some stuff on the mailing list, but I think it would be better to document all this stuff on a central place, also with regard to get these things rated. Robert 2011/6/17 Lester Caine les...@lsces.co.uk Sebastian Bergmann wrote: [...] Hello Robert, welcome to this list. I think it would be best if you propose the patches individually instead of proposing one big patch. Especially with little nuggets like Deleted short open tags and ?php= is the new ?= Don't have time to go through everything else there so there may be others that are not acceptable. $_REQUEST certainly has a place in my code base ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=**contacthttp://lsces.co.uk/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.phphttp://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP patches
On Jun 20, 2011, at 7:01 AM, Robert Eisele wrote: Could I please get an wiki account? I've posted some stuff on the mailing list, but I think it would be better to document all this stuff on a central place, also with regard to get these things rated. Greetings Robert, Considering the number of patches you've already shown, I think applying for an SVN account would work better as it'd give you full wiki access. We can worry about karma (commit rights) later. - http://php.net/svn-php Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] foreach() for strings
On Mon Jun 20 09:11 AM, Lee davis wrote:
Could we also use current(), next() and key() for iteration of strings?
$string = 'string';
while ($char = current($string))
{
echo key($string) // Would output the offset position I assume 0,1,2
etc??
echo $char // outputs each letter of string
next($string);
}
Hopefully it can be supported without sacrificing too much performance
Like others mentioned, it seems important to distinguish between binary/byte
and text iteration.
$string = new ByteIterator('string é');
foreach($string as $i = $byte)
...
$string = new TextIterator('string é');
foreach($string as $i = $char)
...
When most developers get a 'string' from a database, my hunch is they assume
they would be iterating over the 'characters' (utf8, iso.. encoding) and not
individual bytes.
So +1 to string iteration as long as there's byte iteration and some plan
for text iteration / by character (with icu or not).
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Standard constants as part of the lexer
Hi,
On Mon, Jun 20, 2011 at 13:12, Robert Eisele rob...@xarg.org wrote:
2011/6/20 Derick Rethans der...@php.net
On Mon, 20 Jun 2011, Robert Eisele wrote:
The constants true, false and null are used very often. Unfortunately,
every usage of either of these constants invokes a constant lookup.
There is no problem with this, constant lookups are fast, but I
nevertheless implemented these constants directly in the lexer to
avoid these lookups. I'd be glad to see this change in 5.4 as the
performance enhancement would be a steal.
Would that not break the following code?:
?php
class bar
{
function true()
{
return true;
}
}
$A = new bar;
$A-true();
?
Yes, indeed. But as I wrote, we could add T_SIZEOF (symbol for count +
strlen) and T_LVAL (used for constants) as exception for method and function
names. A more general solution would be better, instead of hacking such
things without deep considerations in an official tree.
Why have them as tokens at all? The optimisation comes from having
specific opcodes, not specific tokens.
We could keep the current tokens, and thus keeping 100% BC, but check
for the content of T_STRING tokens at the parsing level, to dispatch
to specific OPCodes in such cases.
I've also added a new OP code to hard-code count() and strlen() which
improves the performance by ~800%. This is nice, but limits the usage
of count() and strlen() as method name - if no further changes will be
made at the parser. I would rather see a optimization for every
function call in 5.4.x. I'll take a look at this soon, maybe I can
provide a patch for this, too.
Although it's a nice performance increase, I think that breaking
count() as a method name is not a good idea, as I would assume it's
used a lot. Even though count() and strlen() can be optimised that much,
how much does it buy a fully fledged application?
I think it depends on the experience of the developers. There are many -
halfway ugly - PHP optimization tricks on the net. If these are used, the
difference wouldn't that much. But constructs like for($i=0; $istrlen($x);
$i++) could get optimized vigorous.
Then there is also the deliberation on whether it's good to go this
general direction, because I am sure we can make a case to convert every
function into an opcode perhaps.
This would make extension development much more complicated.
cheers,
Derick
grz Robert
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
--
Etienne Kneuss
http://www.colder.ch
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Can't vote yet, as RFC has options (Was: Re: [PHP-DEV] [VOTE] release process RFC)
On Mon, Jun 20, 2011 at 8:30 AM, Derick Rethans der...@php.net wrote: I am not generally against this RFC, but this point needs to be discussed first IMO. As having 5 active branches at the same time for the multiple major releases option is *not* workable. If its because of the constant merges, it would be workable if a DVCS was being used =) Regards, David
Re: [PHP-DEV] Negative string offsets
Hi, On Mon, Jun 20, 2011 at 14:05, Derick Rethans der...@php.net wrote: On Mon, 20 Jun 2011, Robert Eisele wrote: Negative string offsets is a wish and also an implementation of my running PHP version for long. It operates in the same fashion like substr() with negative offsets, but avoids the function call and is much smarter if one single character has to be extracted: $str = Hallo; $str[0] == H $str[-1] == o; If -6 is used as offset, the old warning is displayed because it's the first undefined negative offset. The same thing for setting: $str[-1] = '0'; $str[-4] = 4; will result in H4ll0 Would be glad to see this in 5.4 Sounds like a good addition to me! For ArrayAccess, would this calculate the correct index so that current implementations of ArrayAccess don't have to be changed? Do you mean ArrayObject? ArrayAccess is the interface. Regardless, I don't believe it makes sense to change the semantics of those indexes for arrays, since arrays can define negative indexes. i.e. $a = array(-1 = foo, 2 = bar); $a[-1] should really be foo, and not bar. This looks useful for strings though! cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Etienne Kneuss http://www.colder.ch -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] SVN Account Request: crypt
Developing PHP runtime -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] 5.4 features for vote (long)
Hi, On Fri, Jun 17, 2011 at 00:08, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! Below is the list of the features proposed for inclusion in 5.4, as outlined in https://wiki.php.net/todo/php54. Please read the TODO page and the RFCs linked there for details. This mail is not a vote call but rather description of things that will be put to vote soon. For each one, I'd like to see that: a. It is clear to everybody what is being proposed. If you have any doubts or see that it needs further discussion, please tell. b. We didn't miss something. If you have a proposal that has RFC in good shape, patch (or can have patch within 1 month from now) and you think has to be in 5.4 and has good chance for community support, please tell. I'd love to see the proposal from Felipe about the improved parse errors in that list. I believe that the patch was ready or almost ready? I can't find the RFC though, but maybe the RFC never existed... Best, -- Etienne Kneuss http://www.colder.ch -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Negative string offsets
On 20.06.2011 14:02, Robert Eisele wrote:
Negative string offsets is a wish and also an implementation of my running
PHP version for long. It operates in the same fashion like substr() with
negative offsets, but avoids the function call and is much smarter if one
single character has to be extracted:
$str = Hallo;
$str[0] == H
$str[-1] == o;
If -6 is used as offset, the old warning is displayed because it's the first
undefined negative offset.
The same thing for setting:
$str[-1] = '0';
$str[-4] = 4;
will result in H4ll0
Would be glad to see this in 5.4
While this in itself is a good thing, I'd prefer to wait some more and
get a well thought-through, full fledged solution supporting ranges i.e.
$str[-1:2] or $str[-1,2].
I believe there were talks of such syntax a few years ago, maybe using
{} instead of []. I mean, right now both [] and {} seem to work equally
on strings and arrays, but changing {} to make it behave more like
substr/array_slice might be a viable BC break (for the negative numbers
that might exist in arrays that is).
Cheers
--
Jordi Boggiano
@seldaek - http://nelm.io/jordi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Negative string offsets
+1, seems useful. On Mon, Jun 20, 2011 at 8:02 AM, Robert Eisele rob...@xarg.org wrote: Negative string offsets is a wish and also an implementation of my running PHP version for long. It operates in the same fashion like substr() with negative offsets, but avoids the function call and is much smarter if one single character has to be extracted: $str = Hallo; $str[0] == H $str[-1] == o; If -6 is used as offset, the old warning is displayed because it's the first undefined negative offset. The same thing for setting: $str[-1] = '0'; $str[-4] = 4; will result in H4ll0 Would be glad to see this in 5.4 Robert -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] foreach() for strings
As long as it works on a premise that a string is a byte array and each element represents 1 byte, +1 from me. On Mon, Jun 20, 2011 at 7:27 AM, Robert Eisele rob...@xarg.org wrote: foreach() has many functions, looping over arrays, objects and implementing the iterator interface. I think it's also quite intuitive to use foreach() for strings, too. If you want to implement a parser in PHP, you have to go the way with for + strlen + substr() or $x[$i] to address one character of the string. We could overdo the functionality of foreach() by implementing LVAL's, too, in order to access single bits but this is really uncommon, even if the way of thinking could be, that foreach() gives a single attribute of each value, no matter if it's a complex object with the iterator interface or a primitive. What do you think about this one? My point of view is, that foreach() is very useful, which was acknowledged by many ppl via the comments of my article. I think, adding features like this persuades the one or the other PHP user to upgrade to 5.4. Robert -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] foreach() for strings
-Original Message-
From: Lee davis [mailto:leedavi...@gmail.com]
Sent: Monday, June 20, 2011 9:12 AM
To: Robert Eisele
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] foreach() for strings
I think this would be quite a useful feature, and am In favor of it.
However, I think caution should be taken when shifting array utilities out
of their remit and allowing them to manipulate / traverse other data types.
You may see the floodgates opening for more request to adapt array functions
for other uses.
Say for instance..
Could we also use current(), next() and key() for iteration of strings?
$string = 'string';
while ($char = current($string))
{
echo key($string) // Would output the offset position I assume 0,1,2 etc??
echo $char // outputs each letter of string
next($string);
}
Lee
On Mon, Jun 20, 2011 at 12:27 PM, Robert Eisele rob...@xarg.org wrote:
foreach() has many functions, looping over arrays, objects and implementing
the iterator interface. I think it's also quite intuitive to use foreach()
for strings, too.
If you want to implement a parser in PHP, you have to go the way with for +
strlen + substr() or $x[$i] to address one character of the string. We
could
overdo the functionality of foreach()
by implementing LVAL's, too, in order to access single bits but this is
really uncommon, even if the way of thinking could be, that foreach() gives
a single attribute of each value, no matter
if it's a complex object with the iterator interface or a primitive. What
do
you think about this one? My point of view is, that foreach() is very
useful, which was acknowledged by many ppl via the comments of my article.
I think, adding features like this persuades the one or the other PHP user
to upgrade to 5.4.
Robert
Doing this with an explicit iterator object is a fine idea. The syntax becomes
something like:
foreach(new TextIterator($s, 'UTF8') as $pos=$c)
{
...
}
On the other hand, I think that trying to support iteration without using an
iterator object to mediate would be a disaster, and I'm opposed to doing
something like that because:
1. The code just looks wrong. PHP developers are generally insulated from the
char-arrayness of strings. In addition, since PHP isn't typesafe, the code
becomes highly ambiguous. Is the code iterating an array, or a string? It is
very hard to tell just by looking. It may be convenient to write, but it's
certainly not convenient to read or maintain later. On the other hand, with a
mediating iterator object, the intent becomes obvious, and the code is highly
readable.
2. The odds of iterating any given string are slim at best. Supporting current,
key, next, etc. would require the string object internally to get bloated with
additional unnecessary data that is almost never used. This bloat isn't a
single int either. For optimal performance it would need to consist of no less
than two size_t (char position and binary position), and one encoding indicator.
3. Iteration cannot work without knowing which encoding to use for the string.
Is it UTF8? UTF16? UTF7? Binary or some single byte encoding? Some other exotic
wide encoding? Without an iterator object in the middle, there is no way to
specify this encoding. Always treating this as binary would also be a mistake,
since this is almost certainly never actually the correct behavior, even though
it may often appear to behave correctly with simple inputs.
4. I've had simple mistakes caught numerous times when foreach complains about
getting a scalar rather than an array. So far, it has been exactly right every
time. Allowing strings to be iterated would, in the name of convenience,
increase the probability of stupid mistakes evading detection. Even worse, the
code itself would look logically correct until the developer finally realizes
that they have a string and not an array. Errors like this are probably far
more common in most projects than the need to iterate a string, so making this
change hurts debugging in the common case, for the sake of syntactic sugar in
the rare case. Not a good trade.
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Can't vote yet, as RFC has options (Was: Re: [PHP-DEV] [VOTE] release process RFC)
On Mon, 2011-06-20 at 09:28 -0500, dukeofgaming wrote: On Mon, Jun 20, 2011 at 8:30 AM, Derick Rethans der...@php.net wrote: I am not generally against this RFC, but this point needs to be discussed first IMO. As having 5 active branches at the same time for the multiple major releases option is *not* workable. If its because of the constant merges, it would be workable if a DVCS was being used =) Even then it is hard. The pure merging is one thing. But for merging you first need to evaluate whether the patch is needed in the branch and test the patch on every branch. Over time the branches will diverge. Even if a patch applies it might be the wrong thing for a branch. And then every of these branches should be released. For a release one needs QA cycles etc. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Negative string offsets
On Mon, 2011-06-20 at 16:31 +0200, Etienne Kneuss wrote:
Negative string offsets is a wish and also an implementation of my running
PHP version for long. It operates in the same fashion like substr() with
negative offsets, but avoids the function call and is much smarter if one
single character has to be extracted:
Do you mean ArrayObject? ArrayAccess is the interface.
Regardless, I don't believe it makes sense to change the semantics of
those indexes for arrays, since arrays can define negative indexes.
i.e. $a = array(-1 = foo, 2 = bar); $a[-1] should really be
foo, and not bar.
This clearly shows the inconsistency this brings. Maybe $var{$offset}
should be clearly deprecated for arrays and $var[$offset] for strings as
in PHP they work differently.
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Negative string offsets
I would push this out in two steps. First: Negative string offset and later
range/slice
support for objects and strings. Objects would need a new magic method,
e.g. __slice(),strings need a substr() like interface. I think both are
accessed the
same way, but way are different. The slice support is furthermore much more
comprehensive and needs more testing and so on.
BTW: I can dimly remember that {} vs [] was already concluded in favor of []
for string access.
Robert
2011/6/20 Jordi Boggiano j.boggi...@seld.be
On 20.06.2011 14:02, Robert Eisele wrote:
Negative string offsets is a wish and also an implementation of my
running
PHP version for long. It operates in the same fashion like substr() with
negative offsets, but avoids the function call and is much smarter if one
single character has to be extracted:
$str = Hallo;
$str[0] == H
$str[-1] == o;
If -6 is used as offset, the old warning is displayed because it's the
first
undefined negative offset.
The same thing for setting:
$str[-1] = '0';
$str[-4] = 4;
will result in H4ll0
Would be glad to see this in 5.4
While this in itself is a good thing, I'd prefer to wait some more and
get a well thought-through, full fledged solution supporting ranges i.e.
$str[-1:2] or $str[-1,2].
I believe there were talks of such syntax a few years ago, maybe using
{} instead of []. I mean, right now both [] and {} seem to work equally
on strings and arrays, but changing {} to make it behave more like
substr/array_slice might be a viable BC break (for the negative numbers
that might exist in arrays that is).
Cheers
--
Jordi Boggiano
@seldaek - http://nelm.io/jordi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] 5.4 features for vote (long)
Hi, 2011/6/20 Etienne Kneuss col...@php.net Hi, On Fri, Jun 17, 2011 at 00:08, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! Below is the list of the features proposed for inclusion in 5.4, as outlined in https://wiki.php.net/todo/php54. Please read the TODO page and the RFCs linked there for details. This mail is not a vote call but rather description of things that will be put to vote soon. For each one, I'd like to see that: a. It is clear to everybody what is being proposed. If you have any doubts or see that it needs further discussion, please tell. b. We didn't miss something. If you have a proposal that has RFC in good shape, patch (or can have patch within 1 month from now) and you think has to be in 5.4 and has good chance for community support, please tell. I'd love to see the proposal from Felipe about the improved parse errors in that list. I believe that the patch was ready or almost ready? I can't find the RFC though, but maybe the RFC never existed... Best, https://wiki.php.net/rfc/improved-parser-error-message -- Regards, Felipe Pena
Re: [PHP-DEV] Negative string offsets
I would not consider this for arrays and objects, too. If we had real
arrays, this would make sense but they are HT's and therewith it can also be
explained that -1 is an element and not the end of the chained list behind
the HT.
2011/6/20 Johannes Schlüter johan...@schlueters.de
On Mon, 2011-06-20 at 16:31 +0200, Etienne Kneuss wrote:
Negative string offsets is a wish and also an implementation of my
running
PHP version for long. It operates in the same fashion like substr()
with
negative offsets, but avoids the function call and is much smarter if
one
single character has to be extracted:
Do you mean ArrayObject? ArrayAccess is the interface.
Regardless, I don't believe it makes sense to change the semantics of
those indexes for arrays, since arrays can define negative indexes.
i.e. $a = array(-1 = foo, 2 = bar); $a[-1] should really be
foo, and not bar.
This clearly shows the inconsistency this brings. Maybe $var{$offset}
should be clearly deprecated for arrays and $var[$offset] for strings as
in PHP they work differently.
johannes
Re: [PHP-DEV] [RFC] 5.4 features for vote (long)
On Mon, 20 Jun 2011, Felipe Pena wrote:
2011/6/20 Etienne Kneuss col...@php.net
I'd love to see the proposal from Felipe about the improved parse
errors in that list. I believe that the patch was ready or almost
ready? I can't find the RFC though, but maybe the RFC never existed...
https://wiki.php.net/rfc/improved-parser-error-message
I think this is good and helpful.
I've two suggestions though:
- Add the token name in parenthesis at the end of the string
- Add '' around the token strings
Examples:
Parse error: syntax error, unexpected '=' (T_SL_EQUAL) in Command line code
on line 1
Parse error: syntax error, unexpected '::' (T_PAAMAYIM_NEKUDOTAYIM) in
Command line code on line 1
Parse error: syntax error, unexpected 'quoted-string'
(T_CONSTANT_ENCAPSED_STRING), expecting identifier or '(' in Command line code
on line 1
And we need to make sure to check for escaped and in HTML error
messages :)
cheers,
Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Negative string offsets
On Mon, 2011-06-20 at 17:49 +0200, Robert Eisele wrote:
I would not consider this for arrays and objects, too. If we had real
arrays, this would make sense but they are HT's and therewith it can also be
explained that -1 is an element and not the end of the chained list behind
the HT.
Yes. So having this in the current form accepted means that
$a[-1];
can have two meanings:
1) Get the last item (byte in a string)
2) Get item `-1` (in an array)
Which are to different things.
Currently we treat
$a{$o} and $a[$o]
as equal. My suggestion was to split this up to avoid the conflict from
above. I didn't suggest adding support for $a[-1] as last element for
arrays, I know quite well why this won't make sense.
johannes
2011/6/20 Johannes Schlüter johan...@schlueters.de
On Mon, 2011-06-20 at 16:31 +0200, Etienne Kneuss wrote:
Negative string offsets is a wish and also an implementation of my
running
PHP version for long. It operates in the same fashion like substr()
with
negative offsets, but avoids the function call and is much smarter if
one
single character has to be extracted:
Do you mean ArrayObject? ArrayAccess is the interface.
Regardless, I don't believe it makes sense to change the semantics of
those indexes for arrays, since arrays can define negative indexes.
i.e. $a = array(-1 = foo, 2 = bar); $a[-1] should really be
foo, and not bar.
This clearly shows the inconsistency this brings. Maybe $var{$offset}
should be clearly deprecated for arrays and $var[$offset] for strings as
in PHP they work differently.
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Negative string offsets
2011/6/20 Johannes Schlüter johan...@schlueters.de
On Mon, 2011-06-20 at 17:49 +0200, Robert Eisele wrote:
I would not consider this for arrays and objects, too. If we had real
arrays, this would make sense but they are HT's and therewith it can also
be
explained that -1 is an element and not the end of the chained list
behind
the HT.
Yes. So having this in the current form accepted means that
$a[-1];
can have two meanings:
1) Get the last item (byte in a string)
2) Get item `-1` (in an array)
Yes, sure. But if this feature is documented well, I can't see any
problems with this, especially if the trend goes towards a more
typed language where the user knows about the used data-type.
Which are to different things.
Currently we treat
$a{$o} and $a[$o]
as equal. My suggestion was to split this up to avoid the conflict from
above. I didn't suggest adding support for $a[-1] as last element for
arrays, I know quite well why this won't make sense.
I know about the equality of the two bracket forms. But I read somewhere
that
the trend goes towards [] - and maybe it was something from you.
johannes
2011/6/20 Johannes Schlüter johan...@schlueters.de
On Mon, 2011-06-20 at 16:31 +0200, Etienne Kneuss wrote:
Negative string offsets is a wish and also an implementation of my
running
PHP version for long. It operates in the same fashion like
substr()
with
negative offsets, but avoids the function call and is much smarter
if
one
single character has to be extracted:
Do you mean ArrayObject? ArrayAccess is the interface.
Regardless, I don't believe it makes sense to change the semantics of
those indexes for arrays, since arrays can define negative indexes.
i.e. $a = array(-1 = foo, 2 = bar); $a[-1] should really be
foo, and not bar.
This clearly shows the inconsistency this brings. Maybe $var{$offset}
should be clearly deprecated for arrays and $var[$offset] for strings
as
in PHP they work differently.
johannes
Re: [PHP-DEV] foreach() for strings
Hi! foreach() has many functions, looping over arrays, objects and implementing the iterator interface. I think it's also quite intuitive to use foreach() for strings, too. I'm not sure how you'd implement such thing, but then I think things like next(), end(), etc. should work 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] foreach() for strings
From: Ilia Alshanetsky [mailto:i...@prohost.org] As long as it works on a premise that a string is a byte array and each element represents 1 byte, +1 from me. Code written on this premise is almost always bug central when people finally get around to realizing why they really do need to support wide characters (and everybody does, because people like to paste stuff containing non-break-spaces, and decorative quotes). I really don't think this single byte character mentality should be encouraged. Also, how do you think this will work with the Unicode conversion in PHP 6? Guaranteed, this will break stuff. Some people will have written code to iterate characters, assuming single byte characters, some people will have written code ACTUALLY intending to iterate as a byte array. Sadly, we can almost certainly assume that the single byte characters assumption (which is wrong) will also be, by far, the most common. Supporting that most common case when moving to PHP 6 would require breaking the binary case (which was the only properly written code in the first place.) On the other hand, supporting the binary case means breaking the most common case. John Crenshaw Priacta, Inc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Negative string offsets
Hi! Negative string offsets is a wish and also an implementation of my running PHP version for long. It operates in the same fashion like substr() with negative offsets, but avoids the function call and is much smarter if one single character has to be extracted: $str = Hallo; Sounds OK, but what would happen if I do $str[-10] = '?'; ? Would be glad to see this in 5.4 For that you'll need RFC with attached patch ready quite soon. -- 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
[PHP-DEV] Annotations / Interceptors
Hi, I am new to the list and just got done doing a search through the archives to try and get an idea on where things stand in regards to annotation support in PHP. Although I did find some interesting debates, I was not really able to conclude one way or the other what the plan is. I've noticed some patches that have been submitted to the rfc wiki which have been declined, and I am seeing a lot of mixed feelings on whether or not PHP 'should' support them. What is the official position on annotations? I for one would really like to see this supported. I have been experimenting with annotations/interceptors in my framework for the last year or so, and I love them. The only problem I have is performance - this needs to be handled in the core. One thing I figured I would mention, is it seems like most people want annotations to be part of the reflection package. While this makes sense in the context of annotations, I think this would prevent annotations from being used as the foundation to interceptors, since a class level interceptor would need to get executed before the intercepted class is instantiated. As I understand reflection to work today, this would not be possible. I'm more than happy to contribute to an extension with those who share similiar feelings. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] 5.4 alpha
Hi! Since we've got voting on the process RFCs finally going on, after much deliberation we've decided it'd be best to let the votes finish before the first official 5.4 release. Thus, we decided to postpone 5.4 alpha 1 until June 28th (next Tuesday). The updated schedule is at https://wiki.php.net/todo/php54 , please check out. -- 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] [RFC] 5.4 features for vote (long)
Hi!
On 6/20/11 4:39 AM, Derick Rethans wrote:
On Thu, 16 Jun 2011, Stas Malyshev wrote:
3. Add E_STRICT to E_ALL. Nuff said. We did it in 6.0/unicode branch but
didn't backport it.
Not sure about that. Can't we just tell people to use -1 ?
Well, yes, but a) we had it in 6.0 and b) ALL not meaning all is weird.
6. Array shortcuts. Make [ 'blah', 'blah' ] work same as array('blah',
'blah'), etc. Does not include any new JSON-like syntax, etc. - just making
'[' be 'array(' and ']' be ')' in that context.
And for associative arrays only = ?
Yes.
--
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] [RFC] 5.4 features for vote (long)
Hi! I'd love to see the proposal from Felipe about the improved parse errors in that list. I believe that the patch was ready or almost ready? I can't find the RFC though, but maybe the RFC never existed... Thanks, missed it. I think based on the discussion and wide acceptance we could put it on the TODO. -- 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
[PHP-DEV] Re: foreach() for strings
Adding to John Crenshaw's list of reasons not to implicitly
treat strings as arrays in foreach loops... Please keep in
mind the following valid code:
$s = 'hello';
foreach ((array)$s as $x) {
var_dump($x);
}
The result is:
string(5) hello
That behavior can be handy. Hopefully, a BC break wouldn't
occur if any of the string features currently being discussed
are implemented. Without a BC break, having strings implicitly
be treated as arrays in foreach loops will seem very strange
in cases like the above.
Iterators are nice. Having a text_string_to_array function
would also be fine. For example:
$s = 'hello';
foreach (text_string_to_array($s) as $x) {
var_dump($x);
}
The result would be:
string(1) h
string(1) e
string(1) l
string(1) l
string(1) o
I don't know enough about the internals to say for sure, but
perhaps text_string_to_array() could be implemented as creating
a reference to the string that has a flag set that causes
it to be allowed to be treated as an array. (A full conversion
might be needed it were written to. For example,
$a = text_string_to_array($s); $a[0] = 5; )
- Todd
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Changed behaviour for strtr()
Hi! Here is the next one. I think it's quite intuitive to use strtr() to remove single characters of a string, too, instead of using many str_replace($str, $chr, ). I'd glad to see this change also in 5.4. This is a BC break, if I understand it correctly, so I don't think it is a good idea. -- 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] Re: foreach() for strings
Hi!
On 6/20/11 9:57 AM, Todd Ruth wrote:
Iterators are nice. Having a text_string_to_array function
would also be fine. For example:
$s = 'hello';
foreach (text_string_to_array($s) as $x) {
var_dump($x);
}
text_to_array($s) == str_split($s, 1)
--
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] Changed behaviour for strtr()
Em Mon, 20 Jun 2011 12:32:30 +0100, Robert Eisele rob...@xarg.org escreveu: $demise = strtr(passion, os, ); This is a very bad idea for several reasons: - strtr already does this with: $demise = strtr(passion, array(o = , s = )); - it's a BC break - adds a *third* operation mode to strtr, which (IMO unwisely) already provides two completely different algorithms. -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Standard constants as part of the lexer
Hi! On 6/20/11 4:12 AM, Robert Eisele wrote: I think it depends on the experience of the developers. There are many - halfway ugly - PHP optimization tricks on the net. If these are used, the difference wouldn't that much. But constructs like for($i=0; $istrlen($x); $i++) could get optimized vigorous. If you're microoptimizing, you should not do this unless $x is a dynamic string, so I'm not sure messing with strlen is the right way to improve it. Also, I really do not like splitting strlen()/count() code into two places. It hurts maintainability and will lead to weird BC problems. I'm not sure if the optimization is worth it, but if it is, it should be done differently, with only one code for any strlen()/count() implementation. Also, I don't see why strlen/count should share an opcode if there's absolutely no common implementation code between them. -- 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] PHP patches
On Mon, 2011-06-20 at 07:11 -0700, Philip Olson wrote: On Jun 20, 2011, at 7:01 AM, Robert Eisele wrote: Could I please get an wiki account? I've posted some stuff on the mailing list, but I think it would be better to document all this stuff on a central place, also with regard to get these things rated. Greetings Robert, Considering the number of patches you've already shown, I think applying for an SVN account would work better as it'd give you full wiki access. We can worry about karma (commit rights) later. He did and according to master.php.net the account was granted. Robert, you should be able to login using your svn data to the wiki. :-) johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Negative string offsets
2011/6/20 Stas Malyshev smalys...@sugarcrm.com Hi! Negative string offsets is a wish and also an implementation of my running PHP version for long. It operates in the same fashion like substr() with negative offsets, but avoids the function call and is much smarter if one single character has to be extracted: $str = Hallo; Sounds OK, but what would happen if I do $str[-10] = '?'; ? As I wrote: If -6 is used as offset, the old warning is displayed because it's the first undefined negative offset. Would be glad to see this in 5.4 For that you'll need RFC with attached patch ready quite soon. I'll attach a patch in 2 days (still have to wait for the new power cable of my macbook) -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227
Re: [PHP-DEV] Re: foreach() for strings
text_to_array($s) == str_split($s, 1)
No, because str_split always splits into 1 byte chunks. text_to_array
would take the character set into account (or that's where the utility
in it would be)...
On Mon, Jun 20, 2011 at 1:06 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
On 6/20/11 9:57 AM, Todd Ruth wrote:
Iterators are nice. Having a text_string_to_array function
would also be fine. For example:
$s = 'hello';
foreach (text_string_to_array($s) as $x) {
var_dump($x);
}
text_to_array($s) == str_split($s, 1)
--
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: foreach() for strings
On Mon, 2011-06-20 at 10:06 -0700, Stas Malyshev wrote:
Hi!
On 6/20/11 9:57 AM, Todd Ruth wrote:
Iterators are nice. Having a text_string_to_array function
would also be fine. For example:
$s = 'hello';
foreach (text_string_to_array($s) as $x) {
var_dump($x);
}
text_to_array($s) == str_split($s, 1)
Does that have approximately the same performance as marking the
string as being OK to use as an array? For example,
$s = file_get_contents($big_file);
foreach (str_split($s, 1) as $x) {
f($x);
}
Are there performance issues with the above compared to:
$s = file_get_contents($big_file);
foreach (text_string_to_array($s) as $x) {
f($x);
}
assuming text_string_to_array could be implemented as marking
the string OK to use as an array.
Again, I don't know enough about the internals. I'm just imagining
a significant difference for very long strings between:
$a1 = text_to_array('hello');
and
$a2 = array('h','e','l','l','o');
$a1 and $a2 could act identically until a set occurred. For example,
$a1['key'] = 5; would first trigger $a1 becoming just like $a2 so
that the set could take place.
Any string that has not been hit with text_string_to_array would lead
to all the usual error messages some of us know and love and
any string that has been hit with text_string_to_array would allow all
the fancy features some people are seeking. I'm trying to find a
way to please the people that want strings to act like arrays without
ruining the day for those of us who are glad strings don't act like
arrays.
- Todd
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Changed behaviour for strtr()
Stas, Why should it be a BC break? Empty strings are not considered, in any mode or what feature of strtr() did I miss? Gustavo, does you not constradict yourself, when you say it's already available in the one mode and in the other it shouldn't be? What about the intuitive and nosy developers that expects this feature in both modes, the array-mode and the string-mode? And yes, it would be a third completely different algorithm. But every algorithm is specialized for one use-case, and I think we shouldn't decide such things based on the number of algorithms used; especially for such a basic function where the result should be calculated as fast as possible, no matter which algorithm led to the final result. You also call it a BC break, what did I missed? If we agree with this feature, we could, of course, search for a different syntax; but it was the most obvious. Robert 2011/6/20 Gustavo Lopes glo...@nebm.ist.utl.pt Em Mon, 20 Jun 2011 12:32:30 +0100, Robert Eisele rob...@xarg.org escreveu: $demise = strtr(passion, os, ); This is a very bad idea for several reasons: - strtr already does this with: $demise = strtr(passion, array(o = , s = )); - it's a BC break - adds a *third* operation mode to strtr, which (IMO unwisely) already provides two completely different algorithms. -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Changed behaviour for strtr()
Hi! On 6/20/11 10:56 AM, Robert Eisele wrote: Stas, Why should it be a BC break? Empty strings are not considered, in any mode or what feature of strtr() did I miss? Because now strtr(passion, os, ) returns different result. Combined with the fact that you already can do it with array syntax, I don't really see a point. -- 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] PHP patches
Thanks, Johannes! :) It works. 2011/6/20 Johannes Schlüter johan...@schlueters.de On Mon, 2011-06-20 at 07:11 -0700, Philip Olson wrote: On Jun 20, 2011, at 7:01 AM, Robert Eisele wrote: Could I please get an wiki account? I've posted some stuff on the mailing list, but I think it would be better to document all this stuff on a central place, also with regard to get these things rated. Greetings Robert, Considering the number of patches you've already shown, I think applying for an SVN account would work better as it'd give you full wiki access. We can worry about karma (commit rights) later. He did and according to master.php.net the account was granted. Robert, you should be able to login using your svn data to the wiki. :-) johannes
[PHP-DEV] Re: [VOTE] release process RFC
Le Mon, 20 Jun 2011 14:59:51 +0200, Pierre Joye a écrit : Hi Internals, We have been working on getting this rfc on how to have clear and transparent releases process, release cycles and how and which features get into a release. The RFC is finally ready for the votes. Therefore we call for votes on the release process RFC. The RFC can be found here: https://wiki.php.net/rfc/releaseprocess You can vote here: https://wiki.php.net/rfc/releaseprocess/vote Votes are open until Monday 27.06.2011. Thank you, Hi, I can't vote but I give my full support to this RFC. It is a great improvement of the process which will give a better visibility on the releases. Bruno -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PATCH] Notice on array to string convertion
2011/6/2 Patrick ALLAERT patrickalla...@php.net: Hi, I would like to introduce an E_NOTICE when an array is silently converted to a string. This isn't very useful as it constantly produces the following string: Array and in most of the case, this is a sign of an error. Let me know about your feelings. Patch implementing that behavior change: https://gist.github.com/1004203 Patch to adapt the tests: https://gist.github.com/1004204 Cheers, Patrick Final patch to be committed is at: https://gist.github.com/1036136 (git diff) Please, apply it on trunk or increase my karma to do it (Access denied: Insufficient karma for patrickallaert to php/php-src/trunk/Zend/zend.c.), thanks. @Stas, DSP Would you agree to merge this into PHP 5.4? Thanks in advance, Patrick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: foreach() for strings
I really like the ideas shared here. It's a thing of consideration that
array-functions should also work with strings. Maybe this would be the way
to go, but I'm more excited about the OOP implementation of TextIterator and
ByteIterator, which solves the whole problem at once (and is easier to
implement, as mentioned by Stas). As Jonathan said, Database results with a
certain encoding could get iterated, too. The only way to workaround the
Text/Byte problem would be, offsetting EVERY string with 1-2 byte
string-type information or an additional type flag in the zval-strcuture.
Handling everything with zval's instead of objects would have the advantage,
that database-layers like mysqlnd could write the database-encoding directly
into the zval and the user had no need to decide what encoding is used.
A new casting operator (binary) could then cast the string to a 1-byte
array. But this is syntactical sugar over OOP-implementations - I don't know
which one is the better choice.
For example:
$utf8_string = Jägermeister; // information of utf8 ist stored in the zval
foreach ($utf8_string as $k = $v) // would iterate in byte mode
foreach ((binary)$utf8_string as $k = $v) // would iterate in text mode
over this:
$utf8_obj = new ByteIterator(Jägermeister);
foreach ($utf8_obj as $k = $v)
foreach ($utf8_obj-toText() as $k = $v)
I think the first one is easier and would be nicer to average developers
(and lazy programmers like me ;o) )
Todd, I don't like neither str_split() nor text_string_to_array(). Sure,
str_split could be optimized to return a different more optimized result
inside of foreach() but I would use rather one of the implementations,
mentioned above.
2011/6/20 Todd Ruth tr...@proposaltech.com
On Mon, 2011-06-20 at 10:06 -0700, Stas Malyshev wrote:
Hi!
On 6/20/11 9:57 AM, Todd Ruth wrote:
Iterators are nice. Having a text_string_to_array function
would also be fine. For example:
$s = 'hello';
foreach (text_string_to_array($s) as $x) {
var_dump($x);
}
text_to_array($s) == str_split($s, 1)
Does that have approximately the same performance as marking the
string as being OK to use as an array? For example,
$s = file_get_contents($big_file);
foreach (str_split($s, 1) as $x) {
f($x);
}
Are there performance issues with the above compared to:
$s = file_get_contents($big_file);
foreach (text_string_to_array($s) as $x) {
f($x);
}
assuming text_string_to_array could be implemented as marking
the string OK to use as an array.
Again, I don't know enough about the internals. I'm just imagining
a significant difference for very long strings between:
$a1 = text_to_array('hello');
and
$a2 = array('h','e','l','l','o');
$a1 and $a2 could act identically until a set occurred. For example,
$a1['key'] = 5; would first trigger $a1 becoming just like $a2 so
that the set could take place.
Any string that has not been hit with text_string_to_array would lead
to all the usual error messages some of us know and love and
any string that has been hit with text_string_to_array would allow all
the fancy features some people are seeking. I'm trying to find a
way to please the people that want strings to act like arrays without
ruining the day for those of us who are glad strings don't act like
arrays.
- Todd
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] 5.4 features for vote (long)
On 06/20/2011 08:50 AM, Derick Rethans wrote:
On Mon, 20 Jun 2011, Felipe Pena wrote:
2011/6/20 Etienne Kneusscol...@php.net
I'd love to see the proposal from Felipe about the improved parse
errors in that list. I believe that the patch was ready or almost
ready? I can't find the RFC though, but maybe the RFC never existed...
https://wiki.php.net/rfc/improved-parser-error-message
I think this is good and helpful.
I've two suggestions though:
- Add the token name in parenthesis at the end of the string
- Add '' around the token strings
Examples:
Parse error: syntax error, unexpected '=' (T_SL_EQUAL) in Command line
code on line 1
Parse error: syntax error, unexpected '::' (T_PAAMAYIM_NEKUDOTAYIM) in
Command line code on line 1
Parse error: syntax error, unexpected 'quoted-string'
(T_CONSTANT_ENCAPSED_STRING), expecting identifier or '(' in Command line code
on line 1
And we need to make sure to check for escaped and in HTML error
messages :)
cheers,
Derick
Having the script token text is a good idea.
If messages are changing, can we feasibly strip the Bison syntax
error, component? The Command line code component is arguably
useless too. Or at least it could be lower cased to command line,
though changing this in php_cli.c may have an unwanted cascading
effect (?)
An example message:
Parse error: unexpected 'quoted-string' (T_CONSTANT_ENCAPSED_STRING),
expecting identifier or '(' on line 1
Chris
--
Email: christopher.jo...@oracle.com
Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] REMINDER: Participation Requested: Survey about Open-Source Software Development
Hi, Apologies for any inconvenience and thank you to those who have already completed the survey. We will keep the survey open for another couple of weeks. But, we do hope you will consider responding to the email request below (sent 2 weeks ago). Thanks, Dr. Jeffrey Carver Assistant Professor University of Alabama (v) 205-348-9829 (f) 205-348-0219 http://www.cs.ua.edu/~carver -Original Message- From: Jeffrey Carver [mailto:opensourcesur...@cs.ua.edu] Sent: Monday, June 13, 2011 12:04 PM To: 'internals@lists.php.net' Subject: Participation Requested: Survey about Open-Source Software Development Hi, Drs. Jeffrey Carver, Rosanna Guadagno, Debra McCallum, and Mr. Amiangshu Bosu, University of Alabama, and Dr. Lorin Hochstein, University of Southern California, are conducting a survey of open-source software developers. This survey seeks to understand how developers on distributed, virtual teams, like open-source projects, interact with each other to accomplish their tasks. You must be at least 19 years of age to complete the survey. The survey should take approximately 15 minutes to complete. If you are actively participating as a developer, please consider completing our survey. Here is the link to the survey: http://goo.gl/HQnux We apologize for inconvenience and if you receive multiple copies of this email. This survey has been approved by The University of Alabama IRB board. Thanks, Dr. Jeffrey Carver Assistant Professor University of Alabama (v) 205-348-9829 (f) 205-348-0219 http://www.cs.ua.edu/~carver -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] 5.4 features for vote (long)
Hi! On 6/20/11 12:29 PM, Christopher Jones wrote: If messages are changing, can we feasibly strip the Bison syntax error, component? The Command line code component is arguably useless too. Or at least it could be lower cased to command line, though changing this in php_cli.c may have an unwanted cascading effect (?) I would assume Command line code comes from filename component of the metadata for the code being parsed. I guess it would be possible to detect when it's command-line and skip it, but what for? -- 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] Re: foreach() for strings
-Original Message-
From: Anthony Ferrara [mailto:ircmax...@gmail.com]
text_to_array($s) == str_split($s, 1)
No, because str_split always splits into 1 byte chunks. text_to_array
would take the character set into account (or that's where the utility
in it would be)...
I think this does what you want:
function utf8_str_split($s)
{
return preg_split(/(.)/u, $s, null, PREG_SPLIT_DELIM_CAPTURE |
PREG_SPLIT_NO_EMPTY);
}
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: foreach() for strings
2011.06.20 21:38 Robert Eisele rašė: I really like the ideas shared here. It's a thing of consideration that array-functions should also work with strings. Maybe this would be the way to go, but I'm more excited about the OOP implementation of TextIterator and ByteIterator, which solves the whole problem at once (and is easier to implement, as mentioned by Stas). As Jonathan said, Database results with a certain encoding could get iterated, too. The only way to workaround the Text/Byte problem would be, offsetting EVERY string with 1-2 byte string-type information or an additional type flag in the zval-strcuture. Handling everything with zval's instead of objects would have the advantage, that database-layers like mysqlnd could write the database-encoding directly into the zval and the user had no need to decide what encoding is used. A new casting operator (binary) could then cast the string to a 1-byte array. But this is syntactical sugar over OOP-implementations - I don't know which one is the better choice. For example: $utf8_string = Jägermeister; // information of utf8 ist stored in the zval foreach ($utf8_string as $k = $v) // would iterate in byte mode foreach ((binary)$utf8_string as $k = $v) // would iterate in text mode over this: $utf8_obj = new ByteIterator(Jägermeister); foreach ($utf8_obj as $k = $v) foreach ($utf8_obj-toText() as $k = $v) I think the first one is easier and would be nicer to average developers (and lazy programmers like me ;o) ) You assume that string is in utf-8. It can be some iso-8859-x, iso-2022-xx, utf-7, utf-16 or any other multibyte character set. If you want to parse string in symbols, use mb_substr and mb_strlen, set charset correctly and make sure that your string is in correct character set, if PHP bug about inconsistent symbol position calculation is still unfixed. -- Tomas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: foreach() for strings
On Mon, 2011-06-20 at 20:38 +0200, Robert Eisele wrote: I really like the ideas shared here. It's a thing of consideration that array-functions should also work with strings. Maybe this would be the way to go, but I'm more excited about the OOP implementation of TextIterator and ByteIterator, which solves the whole problem at once (and is easier to implement, as mentioned by Stas). As Jonathan said, Database results with a certain encoding could get iterated, too. The only way to workaround the Text/Byte problem would be, offsetting EVERY string with 1-2 byte string-type information or an additional type flag in the zval-strcuture. Handling everything with zval's instead of objects would have the advantage, that database-layers like mysqlnd could write the database-encoding directly into the zval and the user had no need to decide what encoding is used. Welcome back to the failed PHP 6 Unicode project. ;-) (while we didn't store the original encoding but converted to Utf-16, which prevents random/strange conversions in other places when mixing encodings) johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] unregister_shutdown_function()
On 21/06/11 07:41, Arpad Ray wrote: I also think once that functionality is there the next request will be get_registered_shutdown_functions() or something along the lines. I don't see of what use that could be. Completeness? Has that stupid shutdown func been registered? Fair enough, although I should point out that unregister_shutdown_function() returns false if the function hadn't been registered, so if the aim of checking whether it's registered is to remove it then that's unnecessary. Regards, Arpad Unless you want to check if a shutdown function has been registered, and adjust certain behaviour accordingly. eg, you might want to make sure you exit gracefully prior to doing something that might trigger a fatal error. Cheers, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] 5.4 features for vote (long)
2011/6/20 Derick Rethans der...@php.net
On Mon, 20 Jun 2011, Felipe Pena wrote:
2011/6/20 Etienne Kneuss col...@php.net
I'd love to see the proposal from Felipe about the improved parse
errors in that list. I believe that the patch was ready or almost
ready? I can't find the RFC though, but maybe the RFC never existed...
https://wiki.php.net/rfc/improved-parser-error-message
I think this is good and helpful.
I've two suggestions though:
- Add the token name in parenthesis at the end of the string
- Add '' around the token strings
Examples:
Parse error: syntax error, unexpected '=' (T_SL_EQUAL) in Command line
code on line 1
Parse error: syntax error, unexpected '::' (T_PAAMAYIM_NEKUDOTAYIM) in
Command line code on line 1
Parse error: syntax error, unexpected 'quoted-string'
(T_CONSTANT_ENCAPSED_STRING), expecting identifier or '(' in Command line
code on line 1
To have the quoting message working as desired, we need to implement
the yytnamerr function (based in the default one)
e.g.:
static YYSIZE_T zend_yytnamerr(char *yyres, const char *yystr)
{
if (!yyres) {
return yystrlen(yystr);
}
if (*yystr == '') {
YYSIZE_T yyn = 0;
char const *yyp = yystr;
while (1) {
if (*++yyp != '') {
yyres[yyn++] = *yyp;
} else {
yyres[yyn] = '\0';
return yyn;
}
}
}
return yystpcpy (yyres, yystr) - yyres;
}
I'm ok with this, I just think it's ugly to repeat the token name in
the definition in the .y file. :P
%token T_LNUMBER 'number' (T_LNUMBER)
%token T_STRING 'identifier' (T_STRING)
$ sapi/cli/php -r 'function 1'
Parse error: syntax error, unexpected 'number' (T_LNUMBER), expecting
'identifier' (T_STRING) or '(' in Command line code on line 1
--
Regards,
Felipe Pena
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] 5.4 features for vote (long)
On 06/20/2011 08:09 PM, Felipe Pena wrote: I'm ok with this, I just think it's ugly to repeat the token name in the definition in the .y file. :P %token T_LNUMBER 'number' (T_LNUMBER) %token T_STRING 'identifier' (T_STRING) Why 'identifier' and not 'string' or 'string-literal' there? People know what a string is. I am not sure that people know what an identifier is, so in this case changing the error message from something that says expecting T_STRING to expecting identifier isn't making the error message any clearer as far as I am concerned. This is one of the reasons that having the token name there is useful. It provides continuity with the current error messages that people have grown used to. I think we either need the token names, or we need more descriptive names printed. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Can't vote yet, as RFC has options (Was: Re: [PHP-DEV] [VOTE] release process RFC)
Am 20.06.2011 15:30, schrieb Derick Rethans: I am not generally against this RFC, but this point needs to be discussed first IMO. As having 5 active branches at the same time for the multiple major releases option is *not* workable. I agree. -- Sebastian BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
