Re: [PHP-DEV] Make try/catch brackets optinal
2012.07.24. 7:41, Ivan Enderlin @ Hoa ivan.ender...@hoa-project.net ezt írta: On 23/07/12 06:03, Alex Aulbach wrote: In other words: You want to introduce something, which we are glad not to need anymore. :) Ok. And as I said, it is a proposal so… ;-). Next topic: rescue or finally keywoard? For finally see https://bugs.php.net/bug.php?id=32100 it seems that the core devs don't like the idea, but that feature request seems to have a lot of supporters, and comes up frequently.
[PHP-DEV] Working with floats
Hi all, First of all, let me state that the following question is probably going to shun me forever due to the 'basic' nature of the question and the probable misunderstanding of floats in general, but still this got me baffled and i'd like to post this here: Why does the last of the following examples lower my key to 18 BUT does the var dump of the float clearly state 'float(19)' as the actual value: ?php $i = (float)19; var_dump($i); $arr = array($i=1); var_dump($arr); $i = (float)19.00; var_dump($i); $arr = array($i=1); var_dump($arr); $i = (float)18.9; var_dump($i); $arr = array($i=1); var_dump($arr); $i =(float) .19; $i *= 100; var_dump($i); $arr = array($i=1); var_dump($arr); $i =(float) 0.19; $i *= 100; var_dump($i); $arr = array($i=1); var_dump($arr); $i =(float) 1.19; $i -= 1; $i *= 100; var_dump($i); $arr = array($i=1); var_dump($arr); ? I do know this is not really an internals thing, but after fiddling with this for some time, i gave up (bug 32671 might relate to this) Again, if i'm to be regarded as a traditional n00b, i understand as i've seen float / casting discussions before. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: finally, was: Make try/catch brackets optinal
Hi! For finally see https://bugs.php.net/bug.php?id=32100 it seems that the core devs don't like the idea, but that feature request seems to have a lot of supporters, and comes up frequently. I haven't seen it come with a pull req though ;) BTW, look at how finally is implemented in Java, for example, to see why it may not be that easy to do it properly. But if somebody would provide the RFC with a patch, we could discuss it and run a vote and see if it has any support now or not. -- 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] Working with floats
Your CompSci education (or lack thereof) has failed you. Use the source. Floats behave differently under different conditions. -Ronabop -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] VCS Account Request: luballomuyoyo
Developing the PHP runtimeamp;#13;amp;#10;Maintaining an official, bundled PHP extensionamp;#13;amp;#10;Maintaining www.php.netamp;#13;amp;#10;Maintaining the documentationamp;#13;amp;#10;Translating the documentationamp;#13;amp;#10; -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Working with floats
On Tue, Jul 24, 2012 at 1:01 AM, Kingsquare.nl - Robin Speekenbrink ro...@kingsquare.nl wrote: Hi all, [...] Why does the last of the following examples lower my key to 18 BUT does the var dump of the float clearly state 'float(19)' as the actual value: ?php [...] $i =(float) 1.19; $i -= 1; $i *= 100; var_dump($i); $arr = array($i=1); var_dump($arr); ? When displaying floating point numbers, PHP uses the precision config option (http://php.net/precision) so as to shorten output (and to hide rounding errors in some circumstances). If you increase precision to 17 digits or so (64-bit IEEE floating point numbers have a decimal precision of around 15 to 17 digits), the var_dump will reveal that $i is actually 18.993 When you use it as an array index, it ends up converted to an integer, which is done by truncation. If instead you were to convert $i to a string when using it as an index: array($i = 1); array((string)$i = 1); you'd get a result more along the lines that you expect. I do know this is not really an internals thing, but after fiddling with this for some time, i gave up (bug 32671 might relate to this) It's central to what you see, but note that it was decided that the behavior was correct; the bug was in the documentation. Again, if i'm to be regarded as a traditional n00b, i understand as i've seen float / casting discussions before. I think those were more of the how should PHP handle this rather than the why does it do this variety. There is probably a more suitable venue for your question than the internals list; perhaps the general usage list. I can be a bit grumpy about these things, but from what I've seen, the PHP community likes to be inclusive, so I doubt it's a big deal.
Re: [PHP-DEV] Working with floats
Thanks for the reply. I know of the fact that converting the key to a string would be the 'correct' way of using it, i was more curious as to the difference in the var_dump-s... But the precision setting is new to me, i'll have a look into that... That would indeed make the differences in the resulting $i visible and thus explainable to others. Regards, Robin Speekenbrink Op dinsdag 24 juli 2012 10:42:45, Galen Wright-Watson schreef: On Tue, Jul 24, 2012 at 1:01 AM, Kingsquare.nl - Robin Speekenbrink ro...@kingsquare.nl mailto:ro...@kingsquare.nl wrote: Hi all, [...] Why does the last of the following examples lower my key to 18 BUT does the var dump of the float clearly state 'float(19)' as the actual value: ?php [...] $i =(float) 1.19; $i -= 1; $i *= 100; var_dump($i); $arr = array($i=1); var_dump($arr); ? When displaying floating point numbers, PHP uses the precision config option (http://php.net/precision) so as to shorten output (and to hide rounding errors in some circumstances). If you increase precision to 17 digits or so (64-bit IEEE floating point numbers have a decimal precision of around 15 to 17 digits), the var_dump will reveal that $i is actually 18.993 When you use it as an array index, it ends up converted to an integer, which is done by truncation. If instead you were to convert $i to a string when using it as an index: array($i = 1); array((string)$i = 1); you'd get a result more along the lines that you expect. I do know this is not really an internals thing, but after fiddling with this for some time, i gave up (bug 32671 might relate to this) It's central to what you see, but note that it was decided that the behavior was correct; the bug was in the documentation. Again, if i'm to be regarded as a traditional n00b, i understand as i've seen float / casting discussions before. I think those were more of the how should PHP handle this rather than the why does it do this variety. There is probably a more suitable venue for your question than the internals list; perhaps the general usage list. I can be a bit grumpy about these things, but from what I've seen, the PHP community likes to be inclusive, so I doubt it's a big deal. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Internal iteration API
On Sat, Jul 14, 2012 at 2:35 AM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! So, I've not been inside the engine so in practice this may make no sense at all, but what about looking at it the other way around? Vis, instead of making objects more and more like arrays, make arrays an object that happens to implement ArrayAccess, Iterator, and whatever That'd be very nice idea if we were implementing new PHP. I think the fact that arrays are not objects in PHP is a source of many problems. However, right now it probably won't be possible to do it without breaking BC in many places dealing with array copy/assignment/passing semantics. I'd then say : let's keep that idea somewhere to implement it in a new major PHP version. Anyway, there will come a time where we will be developing for PHP6 (or PHP next Major if you prefer), and I think we should use this gap to break BC and add new cool ideas like this one, we seem all to agree with. Julien.P -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] VCS Account Rejected: luballomuyoyo rejected by bjori
Nuked luballomuyoyo -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] VCS Account Request: luballomuyoyo
On Tue, Jul 24, 2012 at 9:35 AM, Jacob Luballo Muyoyo luballomuy...@gmail.com wrote: Developing the PHP runtimeamp;#13;amp;#10;Maintaining an official, bundled PHP extensionamp;#13;amp;#10;Maintaining www.php.netamp;#13;amp;#10;Maintaining the documentationamp;#13;amp;#10;Translating the documentationamp;#13;amp;#10; Please get in contact with the appropriate groups, introduce yourself, and participate in their effort before requesting vcs account -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC Proposal - Attributes read/write visibility
On 7/23/12 12:38 PM, Amaury Bouchard
ama...@amaury.netmailto:ama...@amaury.net wrote:
2012/7/23 André Rømcke andre.rom...@ez.nomailto:andre.rom...@ez.no
I think these two proposals can be synced up, what if:
public readonly $a;
Is shorthand for:
public $a { get; protected set; }
And when no function is defined, no function overhead is added.
Well, this code:
public read-only $a;
introduces a new keyword (that should be avoided when not absolutely necessary).
It's pretty easy to understand what it does (it's an attribute with public
access, but it's not writable), but you loose meanings (visibility).
read-only is already mentioned here:
https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented#read-only_and_write-only_properties
But I see now that it is defined as full read only, not even the class itself
can write to it, so ignore my code examples.
My point was just; we also have the need for public:protected / public:private
and would like to avoid the overhead of function calls, hence why I looked into
if there would be ways to sync the two proposals to improve possibility of
acceptance (ref feedback in thread).
Hence, writing
public $a { get; protected set; }
is more accurate. You recover the lost meaning. But the writing is not
straightforward.
More, should you write
public read-only $a;
or
public $a { get; private set; }
?
Beside, it seems possible to write
public read-only $a { protected get; private set; }
but that doesn't means anything.
Another examples:
public read-only $a;
vs
public:const $a;
public $a { get; private set; }
vs
public:private $a;
public $a { get; protected set; }
vs
public:protected $a;
We must be able to choose the attribute's visibility.
We should be able to read it without having to read some unnecessary code.
The PHP language should be consistent. I think the visibility information
shouldn't be distributed on several locations (before the attribute; sometimes
with a new read-only or write-only keyword; sometimes inside brackets,
before a new get or set keyword).
Re: [PHP-DEV] Implicit isset in ternary operator
On Sun, Jul 22, 2012 at 9:08 PM, Sanford Whiteman swhitemanlistens-softw...@cypressintegrated.com wrote: [...] You do raise (maybe on purpose, not totally clear what you were getting at) the question of whether a more complex (expr1) in one of these theoretical ternarys w/implicit isset, however it is implemented, would apply the isset to _any_ variable in (expr1)? That is, if $a or $b do not exist, does $a $b ?? ... return an error? What if both do not exist? My feeling is that either more complex expressions for operators with an implicit isset or !empty shouldn't work, or that they should cause notices. It's a moot point for null-coalescing operators. Since the proposal is to deal with specific, common usage patterns, it should stay focused on those patterns unless during development it's revealed that a more general case is as easy or easier to implement.
Fwd: [PHP-DEV] Implicit isset in ternary operator
On Sun, Jul 22, 2012 at 8:12 PM, Alex Aulbach alex.aulb...@gmail.comwrote: Do we really need that as operator? Why not using new functions for special cases. There isn't a need in the sense that such an operator makes things possible that otherwise aren't possible. There is a need in that there are common use cases for the ternary operator that are more verbose than they need to be, and such operators would reduce the cases to their shortest expression. Rafael's suggestion follows from the principle (which, for lack of a name, I'd call the Huffman Principle) that (1) common expressions should be succinct, even at (2) the expense of increasing verbosity for less common expressions. The suggestion also betrays the BC principle that new versions of the language should be backwards compatible with others that have the same major version. Later suggestions are both BC compatible and aim to improve expressiveness without sacrificing uncommon cases (part 1 of Huffman without 2, which you could call the Idiom Principle). One other applicable principle is that common usages appearing across the breadth of programs in the language should have language or official library support (core extensions, as opposed to PECL). (Hopefully, my rendition of this principle is accurate, precise and makes sense.) Note that common usages that appear only in programs targeting some narrow subdomain (such as stock trading or medical billing) are excluded from the principle. Since PHP's domain is web development, anything that commonly crops up in same is a candidate. I've yet to identify other competing principles behind some of the alternative suggestions, but would love to hear some that might help settle which approach should be implemented (if any). Don't see much difference between $a = $b ?: $c; and (for example I used i for if) $a = _i($b, $c); When $b is defined, there isn't much appreciable difference. However, this behavior already exists, so there isn't much to debate. In the cases under discussion, a userland function can't suppress undefined variable index notices, so it isn't a viable substitution. PS: Would it be possible to implement functions like :?() or !?() ? Currently this is not allowed by syntax. This could lead to ambiguity in the grammar: /* call function ~-, , or ~ ( - 1)?*/ ~-(1);
Re: [PHP-DEV] Re: finally, was: Make try/catch brackets optinal
On Tue, Jul 24, 2012 at 4:32 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! For finally see https://bugs.php.net/bug.php?id=32100 it seems that the core devs don't like the idea, but that feature request seems to have a lot of supporters, and comes up frequently. I haven't seen it come with a pull req though ;) BTW, look at how finally is implemented in Java, for example, to see why it may not be that easy to do it properly. But if somebody would provide the RFC with a patch, we could discuss it and run a vote and see if it has any support now or not. I will implement one. thanks -- 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 -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
Hi: As the previous threads disscussed, I make a implemention. here is the RFC: https://wiki.php.net/rfc/finally any suggestions? thanks -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
On 24.07.2012, at 15:20, Laruence wrote:
Hi:
As the previous threads disscussed, I make a implemention.
here is the RFC: https://wiki.php.net/rfc/finally
any suggestions?
Will it work without catch in your implementation?
try {
doSomethingDangerous();
} finally {
doCleanup();
}
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
On Tue, Jul 24, 2012 at 12:20 PM, Laruence larue...@php.net wrote:
Hi:
As the previous threads disscussed, I make a implemention.
here is the RFC: https://wiki.php.net/rfc/finally
any suggestions?
thanks
--
Laruence Xinchen Hui
http://www.laruence.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Now this is the kind of stuff that's important to the upcoming
versions of PHP instead of talking about brace-less expressions.
We definitely need this, try {} catch {} finally {}.
Push this for discussion, in two weeks call a vote, I definitely see
this going through.
- Paul.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
On Tue, Jul 24, 2012 at 7:41 PM, Alexey Zakhlestin indey...@gmail.com wrote:
On 24.07.2012, at 15:20, Laruence wrote:
Hi:
As the previous threads disscussed, I make a implemention.
here is the RFC: https://wiki.php.net/rfc/finally
any suggestions?
Will it work without catch in your implementation?
nope for now.
but if it is needed, I can implemente it
thanks
try {
doSomethingDangerous();
} finally {
doCleanup();
}
--
Laruence Xinchen Hui
http://www.laruence.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
On 7/24/2012 5:45 AM, Laruence wrote: On Tue, Jul 24, 2012 at 7:41 PM, Alexey Zakhlestin indey...@gmail.com wrote: On 24.07.2012, at 15:20, Laruence wrote: Will it work without catch in your implementation? nope for now. but if it is needed, I can implemente it Yes, please. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
Thanks Laruence.
If I perform something like this:
function test() {
try {
return 2;
} catch (Exception $e) {
} finally {
return 3;
}
}
What will be returned? There is no possibility to return something in
finally, or finally will overwrite the return?
On Tue, Jul 24, 2012 at 8:45 AM, Laruence larue...@php.net wrote:
On Tue, Jul 24, 2012 at 7:41 PM, Alexey Zakhlestin indey...@gmail.com
wrote:
On 24.07.2012, at 15:20, Laruence wrote:
Hi:
As the previous threads disscussed, I make a implemention.
here is the RFC: https://wiki.php.net/rfc/finally
any suggestions?
Will it work without catch in your implementation?
nope for now.
but if it is needed, I can implemente it
thanks
try {
doSomethingDangerous();
} finally {
doCleanup();
}
--
Laruence Xinchen Hui
http://www.laruence.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Atenciosamente,
Rafael Kassner
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
Hi,
What should a return value in 'finally' mean?
Regards,
Sebastian
2012/7/24 Rafael Kassner kass...@gmail.com
Thanks Laruence.
If I perform something like this:
function test() {
try {
return 2;
} catch (Exception $e) {
} finally {
return 3;
}
}
What will be returned? There is no possibility to return something in
finally, or finally will overwrite the return?
On Tue, Jul 24, 2012 at 8:45 AM, Laruence larue...@php.net wrote:
On Tue, Jul 24, 2012 at 7:41 PM, Alexey Zakhlestin indey...@gmail.com
wrote:
On 24.07.2012, at 15:20, Laruence wrote:
Hi:
As the previous threads disscussed, I make a implemention.
here is the RFC: https://wiki.php.net/rfc/finally
any suggestions?
Will it work without catch in your implementation?
nope for now.
but if it is needed, I can implemente it
thanks
try {
doSomethingDangerous();
} finally {
doCleanup();
}
--
Laruence Xinchen Hui
http://www.laruence.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Atenciosamente,
Rafael Kassner
[PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
Sorry ... to the list instead.
-- Forwarded message --
From: Sebastian Krebs krebs@gmail.com
Date: 2012/7/24
Subject: Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
To: Laruence larue...@php.net
Hi,
2012/7/24 Laruence larue...@php.net
On Tue, Jul 24, 2012 at 7:41 PM, Alexey Zakhlestin indey...@gmail.com
wrote:
On 24.07.2012, at 15:20, Laruence wrote:
Hi:
As the previous threads disscussed, I make a implemention.
here is the RFC: https://wiki.php.net/rfc/finally
any suggestions?
Will it work without catch in your implementation?
nope for now.
but if it is needed, I can implemente it
It is. 'catch()' usually means I can handle it (at least partially), but
when 'finally' it just means, that the current scop wants to clean up ;)
Additional I see myself already, that I misuse it like
$f = fopen($file, 'r+b');
try {
return search_in_file($f);
} finally {
fclose($f);
}
What I mean: I see myself already using 'finally' without ever expecting an
exception, just because it feels so easy to never forget anymore to cleanup
resources. Is this intentionally?
Regards,
Sebastian
thanks
try {
doSomethingDangerous();
} finally {
doCleanup();
}
--
Laruence Xinchen Hui
http://www.laruence.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
Sent from my iPhone
在 2012-7-24，19:51，Rafael Kassner kass...@gmail.com 写道：
Thanks Laruence.
If I perform something like this:
function test() {
try {
return 2;
} catch (Exception $e) {
} finally {
return 3;
}
}
What will be returned? There is no possibility to return something in
finally, or finally will overwrite the return?
overweite，although I think it make no sense return in finally block
But seems java allow that, so I implement it
Thanks
On Tue, Jul 24, 2012 at 8:45 AM, Laruence larue...@php.net wrote:
On Tue, Jul 24, 2012 at 7:41 PM, Alexey Zakhlestin indey...@gmail.com
wrote:
On 24.07.2012, at 15:20, Laruence wrote:
Hi:
As the previous threads disscussed, I make a implemention.
here is the RFC: https://wiki.php.net/rfc/finally
any suggestions?
Will it work without catch in your implementation?
nope for now.
but if it is needed, I can implemente it
thanks
try {
doSomethingDangerous();
} finally {
doCleanup();
}
--
Laruence Xinchen Hui
http://www.laruence.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Atenciosamente,
Rafael Kassner
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
On Tue, Jul 24, 2012 at 1:20 PM, Laruence larue...@php.net wrote: Hi: As the previous threads disscussed, I make a implemention. here is the RFC: https://wiki.php.net/rfc/finally any suggestions? The finally clause comes with a very strong promise that the code in the clause will run in absolutely any case (short of sigkill, maybe). In particular this means that... ... if a die() is execute somewhere in the try clause (or a called function) the finally clause must still be run. ... if a parse error or other fatal error occurs in the try clause (or called function) the finally clause must still be run. ... if the user interrupts the process the finally clause must still be run. Basically this requires that all of the actions that are currently fatal need to be converted to exceptions. E.g. Python has special SystemExit and KeyboardInterrupt exceptions, as well as SyntaxError and so on. I obviously think that PHP should adopt this model too (as it gives the programmer more control), but until all fatal actions are turned into exceptions, I'm strongly against introducing finally. The main point of the clause is to have a guarantee, and that is simply currently not present. You actually get a better guarantee if you just use destructors. Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
On Tue, Jul 24, 2012 at 7:35 AM, Nikita Popov nikita@gmail.com wrote: On Tue, Jul 24, 2012 at 1:20 PM, Laruence larue...@php.net wrote: Hi: As the previous threads disscussed, I make a implemention. here is the RFC: https://wiki.php.net/rfc/finally any suggestions? The finally clause comes with a very strong promise that the code in the clause will run in absolutely any case (short of sigkill, maybe). In particular this means that... ... if a die() is execute somewhere in the try clause (or a called function) the finally clause must still be run. ... if a parse error or other fatal error occurs in the try clause (or called function) the finally clause must still be run. ... if the user interrupts the process the finally clause must still be run. Basically this requires that all of the actions that are currently fatal need to be converted to exceptions. E.g. Python has special SystemExit and KeyboardInterrupt exceptions, as well as SyntaxError and so on. I obviously think that PHP should adopt this model too (as it gives the programmer more control), but until all fatal actions are turned into exceptions, I'm strongly against introducing finally. The main point of the clause is to have a guarantee, and that is simply currently not present. You actually get a better guarantee if you just use destructors. Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php I definitely agree with Mr. Nikita Popov. Unless we have a guarantee of `finally` running for PHP fatal errors, then this is not particularly useful. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
On 24/07/12 14:40, Levi Morrison wrote: On Tue, Jul 24, 2012 at 7:35 AM, Nikita Popov nikita@gmail.com wrote: On Tue, Jul 24, 2012 at 1:20 PM, Laruence larue...@php.net wrote: Hi: As the previous threads disscussed, I make a implemention. here is the RFC: https://wiki.php.net/rfc/finally any suggestions? The finally clause comes with a very strong promise that the code in the clause will run in absolutely any case (short of sigkill, maybe). In particular this means that... ... if a die() is execute somewhere in the try clause (or a called function) the finally clause must still be run. ... if a parse error or other fatal error occurs in the try clause (or called function) the finally clause must still be run. ... if the user interrupts the process the finally clause must still be run. Basically this requires that all of the actions that are currently fatal need to be converted to exceptions. E.g. Python has special SystemExit and KeyboardInterrupt exceptions, as well as SyntaxError and so on. I obviously think that PHP should adopt this model too (as it gives the programmer more control), but until all fatal actions are turned into exceptions, I'm strongly against introducing finally. The main point of the clause is to have a guarantee, and that is simply currently not present. You actually get a better guarantee if you just use destructors. Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php I definitely agree with Mr. Nikita Popov. Unless we have a guarantee of `finally` running for PHP fatal errors, then this is not particularly useful. I also agree with Mr. Popov here. PHP's fatal errors are, well, fatal, meaning we can do absolutely nothing about them. I guess that's something to change for PHP6: making them into serious exceptions, but ones that can be caught (maybe a different class, like Java's RuntimeErrors and Exceptions, IIRC). Obviously things like running out of memory can't be dealt with, though. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
On Tue, 2012-07-24 at 19:20 +0800, Laruence wrote: Hi: As the previous threads disscussed, I make a implemention. here is the RFC: https://wiki.php.net/rfc/finally any suggestions? thanks As PHP has destructors there is less need for finally compared to other languages. What are the cases where an extra language construct is needed? (i.e. one can also use C++-like RAII things ...) The RFC is also missing to demonstrate the order of finally calls in nested try-catch-blocks. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
On 24/07/12 14:48, Johannes Schlüter wrote: On Tue, 2012-07-24 at 19:20 +0800, Laruence wrote: Hi: As the previous threads disscussed, I make a implemention. here is the RFC: https://wiki.php.net/rfc/finally any suggestions? thanks As PHP has destructors there is less need for finally compared to other languages. What are the cases where an extra language construct is needed? (i.e. one can also use C++-like RAII things ...) The RFC is also missing to demonstrate the order of finally calls in nested try-catch-blocks. johannes Tempfiles come to mind. Also, yes, PHP has destructors, but you are not always dealing with custom-made objects to handle this. And you may want something to happen before GC. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
On Tue, 2012-07-24 at 14:50 +0100, Andrew Faulds wrote:
As PHP has destructors there is less need for finally compared to
other languages. What are the cases where an extra language construct is
needed? (i.e. one can also use C++-like RAII things ...)
The RFC is also missing to demonstrate the order of finally calls in
nested try-catch-blocks.
Tempfiles come to mind. Also, yes, PHP has destructors, but you are not
always dealing with custom-made objects to handle this. And you may want
something to happen before GC.
finally is no sufficient way to ensure tempfiles will be delete. Best
approach for that is to delete them after opening (but keep the
handle(s) open) so the OS will guarantee they are deleted. finally might
not be called (in the proposed implementation it isn't called after an
die()/exit() or a fatal error)
When not dealing with custom objects you might wrap them in a
RAII-Container. PHPs GC is mostly refcount-based and well defined. If
you keep a single reference to a RAII-container or something it is well
defined when it will be called. finally rules (especially with nested
try blocks) is an extra thing to be learned.
johannes
P.S. simple, untested, ad hoc example of a quite generic raii container:
class RAIIContainer {
private $cb;
public function __construct(callable $cb) {
$this-cb = $cb;
}
public function __destruct() {
$cb = $this-cb; $cb();
}
}
try {
$file = fopen();
$rc = new RAIIContainer(
function() use ($file) { if ($file) { unlink($file); }});
/* do something /
} catch (SomeException $e) {
}
here unlink will even be called at an exit() or something, certainly can
be made nice ... and yes an extra syntax might be nicer but is it
common enough to excuse making the language larger?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC Proposal - Attributes read/write visibility
Yes, the two proposals can definitely work together. See my initial message:
class A {
// $str has public reading and private writing,
// and manage french quotes
public:private $str {
get { return « . $this-str . »; }
set { $this-str = trim($value, «»); }
}
}
2012/7/24 André Rømcke andre.rom...@ez.no
On 7/23/12 12:38 PM, Amaury Bouchard ama...@amaury.net wrote:
2012/7/23 André Rømcke andre.rom...@ez.no
I think these two proposals can be synced up, what if:
public readonly $a;
Is shorthand for:
public $a { get; protected set; }
And when no function is defined, no function overhead is added.
Well, this code:
public read-only $a;
introduces a new keyword (that should be avoided when not absolutely
necessary).
It's pretty easy to understand what it does (it's an attribute with public
access, but it's not writable), but you loose meanings (visibility).
read-only is already mentioned here:
https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented#read-only_and_write-only_properties
But I see now that it is defined as full read only, not even the class
itself can write to it, so ignore my code examples.
My point was just; we also have the need for public:protected /
public:private and would like to avoid the overhead of function calls,
hence why I looked into if there would be ways to sync the two proposals to
improve possibility of acceptance (ref feedback in thread).
Hence, writing
public $a { get; protected set; }
is more accurate. You recover the lost meaning. But the writing is not
straightforward.
More, should you write
public read-only $a;
or
public $a { get; private set; }
?
Beside, it seems possible to write
public read-only $a { protected get; private set; }
but that doesn't means anything.
Another examples:
public read-only $a;
vs
public:const $a;
public $a { get; private set; }
vs
public:private $a;
public $a { get; protected set; }
vs
public:protected $a;
We must be able to choose the attribute's visibility.
We should be able to read it without having to read some unnecessary code.
The PHP language should be consistent. I think the visibility
information shouldn't be distributed on several locations (before the
attribute; sometimes with a new read-only or write-only keyword;
sometimes inside brackets, before a new get or set keyword).
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
Johannes, On Tue, Jul 24, 2012 at 9:48 AM, Johannes Schlüter johan...@schlueters.dewrote: On Tue, 2012-07-24 at 19:20 +0800, Laruence wrote: Hi: As the previous threads disscussed, I make a implemention. here is the RFC: https://wiki.php.net/rfc/finally any suggestions? thanks As PHP has destructors there is less need for finally compared to other languages. What are the cases where an extra language construct is needed? (i.e. one can also use C++-like RAII things ...) I'm not sure I agree with that statement. Finally is a routine level cleanup tool, while destructors are object level cleanup tools. So while it is possible to make every routine into an object, at some point it just becomes ridiculous. That means that every method that allocates resources would need to be a first-class object, which could get quite messy very fast. If you went by possible, half the proposals for the language wouldn't be accepted (password hashing, generators, goto, Class name to scalar resolution, T_AS for closures, type hints, call-time dereferencing, traits, classes, etc). All of that behavior is possible without the language sugar that they bring. The main drive for adding them is that it makes a developers life a lot easier. Rather than dealing with yet another level of abstraction to add an object, adding a simple finally clause would make implementing that sort of cleanup FAR easier. Additionally, the destructor isn't called until the object goes out of scope. That could be after the method call (a scope block higher). So the only way to fully emulate the finally block would be to construct the object inside of the method in question. So it's not as simple as just put it in a destructor and you'll be fine... My $0.02 at least...
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
On Tue, 2012-07-24 at 10:37 -0400, Anthony Ferrara wrote: If you went by possible, half the proposals for the language wouldn't be accepted (password hashing, generators, goto, Class name to scalar resolution, T_AS for closures, type hints, call-time dereferencing, traits, classes, etc). All of that behavior is possible without the language sugar that they bring. The main drive for adding them is that it makes a developers life a lot easier. Rather than dealing with yet another level of abstraction to add an object, adding a simple finally clause would make implementing that sort of cleanup FAR easier. That's why I asked for cases where this language construct is needed. I, from my personal, limited, experience don't have that many needs for this feature. I however see that it makes try/catch blocks and stack frames more expensive (both in CPU time and memory) and the language more complex. Te best argument I saw in this discussion for adding it was it's possible and I want it. This I don't see as enough reason. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
On Tue, Jul 24, 2012 at 9:35 PM, Nikita Popov nikita@gmail.com wrote: On Tue, Jul 24, 2012 at 1:20 PM, Laruence larue...@php.net wrote: Hi: As the previous threads disscussed, I make a implemention. here is the RFC: https://wiki.php.net/rfc/finally any suggestions? The finally clause comes with a very strong promise that the code in the clause will run in absolutely any case (short of sigkill, maybe). In particular this means that... ... if a die() is execute somewhere in the try clause (or a called function) the finally clause must still be run. ... if a parse error or other fatal error occurs in the try clause (or called function) the finally clause must still be run. ... if the user interrupts the process the finally clause must still be run. I am really can not agree with you on this point. there is runtime error and static error in PHP. it is enough for finally guarantee that the block will be run while *Exception* threw. if in your opinion, then I think finally is also nouse for java, since user could also call exit(some like that ). thank Basically this requires that all of the actions that are currently fatal need to be converted to exceptions. E.g. Python has special SystemExit and KeyboardInterrupt exceptions, as well as SyntaxError and so on. I obviously think that PHP should adopt this model too (as it gives the programmer more control), but until all fatal actions are turned into exceptions, I'm strongly against introducing finally. The main point of the clause is to have a guarantee, and that is simply currently not present. You actually get a better guarantee if you just use destructors. Nikita -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
On 07/24/2012 06:35 AM, Nikita Popov wrote: On Tue, Jul 24, 2012 at 1:20 PM, Laruence larue...@php.net wrote: Hi: As the previous threads disscussed, I make a implemention. here is the RFC: https://wiki.php.net/rfc/finally any suggestions? The finally clause comes with a very strong promise that the code in the clause will run in absolutely any case (short of sigkill, maybe). No it doesn't, at least not in Java. A fatal Java error or an explicit call to System.exit() will cause the finally clause to not be executed. It is a simple exception-level construct and doesn't in any way promise to be called in a fatal error situation. And regardless of what Java does, we are free to define it and provide whatever promises we want here, but keeping it in line with Java's implementation makes sense to me. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
On 24/07/12 16:16, Rasmus Lerdorf wrote:
On 07/24/2012 06:35 AM, Nikita Popov wrote:
On Tue, Jul 24, 2012 at 1:20 PM, Laruence larue...@php.net wrote:
Hi:
As the previous threads disscussed, I make a implemention.
here is the RFC: https://wiki.php.net/rfc/finally
any suggestions?
The finally clause comes with a very strong promise that the code in
the clause will run in absolutely any case (short of sigkill, maybe).
No it doesn't, at least not in Java. A fatal Java error or an explicit
call to System.exit() will cause the finally clause to not be executed.
It is a simple exception-level construct and doesn't in any way promise
to be called in a fatal error situation. And regardless of what Java
does, we are free to define it and provide whatever promises we want
here, but keeping it in line with Java's implementation makes sense to me.
-Rasmus
Yeah, finally{} won't happen in absolutely any case. But if there's an
exception that's uncaught it *should* still run.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] Proposal namespace importing with from syntax
Hi, internals, I'm proposing a improvement to namespace importing. when using 'use' statement to import many classes, we have to duplicate many times even we are importing from the same namespace. I propose a new syntax to import classes\functions\constant in a single statement. here is the example: ?php // reduce use GlobalNamespace\SubSpace\ThirdSpace\Class1; use GlobalNamespace\SubSpace\ThirdSpace\Class2; use GlobalNamespace\SubSpace\ThirdSpace\ForthSpace\Class3; // to from GlobalNamespace\SubSpace\ThirdSace use Class1, Class2 as Alias2, ForthSpace\Class3 as Alias3; ? The above code should be self-explained. More info could be found at the RFC page and the patch. RFC: https://wiki.php.net/rfc/namespace-importing-with-from PATCH : https://github.com/reeze/php-src/compare/rfc-from-use Any Opinion, suggestion, improvement will be much appreciated. Thanks -- reeze | http://reeze.cn
Re: [PHP-DEV] [RFC] Proposal namespace importing with from syntax
On 24/07/12 16:35, Reeze wrote: Hi, internals, I'm proposing a improvement to namespace importing. when using 'use' statement to import many classes, we have to duplicate many times even we are importing from the same namespace. I propose a new syntax to import classes\functions\constant in a single statement. here is the example: ?php // reduce use GlobalNamespace\SubSpace\ThirdSpace\Class1; use GlobalNamespace\SubSpace\ThirdSpace\Class2; use GlobalNamespace\SubSpace\ThirdSpace\ForthSpace\Class3; // to from GlobalNamespace\SubSpace\ThirdSace use Class1, Class2 as Alias2, ForthSpace\Class3 as Alias3; ? The above code should be self-explained. More info could be found at the RFC page and the patch. RFC: https://wiki.php.net/rfc/namespace-importing-with-from PATCH : https://github.com/reeze/php-src/compare/rfc-from-use Any Opinion, suggestion, improvement will be much appreciated. Thanks Ah, so something a la python's from x import y, z? Sounds good. Somewhat surprised we don't already have this. One comment: use Class1, Class2 as Alias2, ... ; confuses me a bit. I read it as use (Class1, Class2) as Alias2, ... ;. //Perhaps this is just a formatting issue (with newlines it would be more clear), but it looks a little weird to me. Just my 2¢. -- Andrew Faulds http://ajf.me/
[PHP-DEV] 回复： [PHP-DEV] [RFC] Proposal namespace importing with from syntax
Hi Andrew, 在 2012年7月24日星期二，下午11:39，Andrew Faulds 写道： On 24/07/12 16:35, Reeze wrote: Hi, internals, I'm proposing a improvement to namespace importing. when using 'use' statement to import many classes, we have to duplicate many times even we are importing from the same namespace. I propose a new syntax to import classes\functions\constant in a single statement. here is the example: ?php // reduce use GlobalNamespace\SubSpace\ThirdSpace\Class1; use GlobalNamespace\SubSpace\ThirdSpace\Class2; use GlobalNamespace\SubSpace\ThirdSpace\ForthSpace\Class3; // to from GlobalNamespace\SubSpace\ThirdSace use Class1, Class2 as Alias2, ForthSpace\Class3 as Alias3; ? The above code should be self-explained. More info could be found at the RFC page and the patch. RFC: https://wiki.php.net/rfc/namespace-importing-with-from PATCH : https://github.com/reeze/php-src/compare/rfc-from-use Any Opinion, suggestion, improvement will be much appreciated. Thanks Ah, so something a la python's from x import y, z? Sounds good. Somewhat surprised we don't already have this. One comment: use Class1, Class2 as Alias2, ... ; confuses me a bit. I read it as use (Class1, Class2) as Alias2, ... ;. //Perhaps this is It means use Class1 **and** use Class2 but aliased with name Alias2 etc. It almost the same as bare 'use' statement, but with a common prefix :) Thanks just a formatting issue (with newlines it would be more clear), but it looks a little weird to me. Just my 2¢. -- Andrew Faulds http://ajf.me/
Re: [PHP-DEV] Implicit isset in ternary operator
2012/7/24 Galen Wright-Watson ww.ga...@gmail.com:
Don't see much difference between
$a = $b ?: $c;
and (for example I used i for if)
$a = _i($b, $c);
When $b is defined, there isn't much appreciable difference. However, this
behavior already exists, so there isn't much to debate. In the cases under
discussion, a userland function can't suppress undefined variable index
notices, so it isn't a viable substitution.
Hm, you're right. I normaly don't do such ugly things. :)
Hum. This behaviour is needed in very special contexts. In my eyes
only when printing out/filling up the templates etc. Under normal
circumstances I think, you should program without too much operators,
because a deflation of operators leads to - hm - deflation of the
language. Thats the same, as if everybody can create new words: after
a short time, nobody can understand anybody.
H. But we can make this to a principle in this very, very closed context.
So: What about if we can create new operators inside PHP with PHP? I
think not more than 36 operators are needed at any time in a project.
So we can do this:
set_operator_handler('i', function ($b, $c) {
if (empty($b)) return $b;
return $b;
}, OPERATOR_HANDLE_UNSET_WITHOUT_WARNINGS)
then we can do this:
$a = $a ?i: $b;
This should help for this case and could be a great things for those
very special cases, when you need the same operation over and over.
Comments
Context: I think those operators should be global.
Security: Hm. Could operators be overwritten? How to test, if an
operator already exists? I think it should work like including a file.
E. g. set_operator_handler_once() should be possible, so that a second
call isn't executed.
Other things: I don't like the first operator (the operator-name). Any
goof idea?
--
Alex Aulbach
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Implicit isset in ternary operator
On 24 ביול 2012, at 19:18, Alex Aulbach wrote:
2012/7/24 Galen Wright-Watson ww.ga...@gmail.com:
Don't see much difference between
$a = $b ?: $c;
and (for example I used i for if)
$a = _i($b, $c);
When $b is defined, there isn't much appreciable difference. However, this
behavior already exists, so there isn't much to debate. In the cases under
discussion, a userland function can't suppress undefined variable index
notices, so it isn't a viable substitution.
Hm, you're right. I normaly don't do such ugly things. :)
Hum. This behaviour is needed in very special contexts. In my eyes
only when printing out/filling up the templates etc. Under normal
circumstances I think, you should program without too much operators,
because a deflation of operators leads to - hm - deflation of the
language. Thats the same, as if everybody can create new words: after
a short time, nobody can understand anybody.
H. But we can make this to a principle in this very, very closed context.
So: What about if we can create new operators inside PHP with PHP? I
think not more than 36 operators are needed at any time in a project.
So we can do this:
set_operator_handler('i', function ($b, $c) {
if (empty($b)) return $b;
return $b;
}, OPERATOR_HANDLE_UNSET_WITHOUT_WARNINGS)
then we can do this:
$a = $a ?i: $b;
This should help for this case and could be a great things for those
very special cases, when you need the same operation over and over.
Comments
Context: I think those operators should be global.
Security: Hm. Could operators be overwritten? How to test, if an
operator already exists? I think it should work like including a file.
E. g. set_operator_handler_once() should be possible, so that a second
call isn't executed.
Other things: I don't like the first operator (the operator-name). Any
goof idea?
--
Alex Aulbach
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I don't think global operators is good idea since it can make a script very
complex and you'll have to learn many operators in case the one who wrote it
decided to make it operator driven
However, if we're talking about operators, I do think that adding operator
override option (for the regular operators, such as +, -, * etc.) will be great
for OOP - but that's a different topic.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
Hi:
try{}finally{} implemented,
https://github.com/laruence/php-src/commit/90cad0a0001ef48396146c69382a25ebe0a60474
the test scripts in that commit are examples
thanks
On Tue, Jul 24, 2012 at 7:41 PM, Alexey Zakhlestin indey...@gmail.com wrote:
On 24.07.2012, at 15:20, Laruence wrote:
Hi:
As the previous threads disscussed, I make a implemention.
here is the RFC: https://wiki.php.net/rfc/finally
any suggestions?
Will it work without catch in your implementation?
try {
doSomethingDangerous();
} finally {
doCleanup();
}
--
Laruence Xinchen Hui
http://www.laruence.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
On Tue, Jul 24, 2012 at 5:16 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: The finally clause comes with a very strong promise that the code in the clause will run in absolutely any case (short of sigkill, maybe). No it doesn't, at least not in Java. A fatal Java error or an explicit call to System.exit() will cause the finally clause to not be executed. It is a simple exception-level construct and doesn't in any way promise to be called in a fatal error situation. And regardless of what Java does, we are free to define it and provide whatever promises we want here, but keeping it in line with Java's implementation makes sense to me. I was writing this out of a Python perspective, which gives strong guarantees for finally. Java indeed reserves the right to not run finally if System.exit is called. Still my point stands. If fatal errors and die are not handled by finally the feature does not make sense to me. You simply can't do any kind of remotely important cleanup in there (like releasing locks etc). Please don't forget that in PHP a lot of stuff throws a fatal error. Some simple oversight like calling $foo-bar()-baz() while $foo-bar() can also return false or null can lead to a fatal error that's easily missed during testing. Similarly die; is commonly called in code doing header redirects. I think it would be unacceptable to not run cleanup clauses in that case. Another, separate point against finally is that in PHP (unlike many other languages) most (all?) built-in resources clean up after themselves. So if you open a file you don't have to worry about closing it again. It'll do that all by itself as soon as it goes out of scope. The same applies to database handles, etc. As PHP uses refcount based garbage collection the resource is actually cleaned up right away, not just at the next GC run (which could be problematic if you open up many files in a row). Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Implicit isset in ternary operator
2012/7/24 Yahav Gindi Bar g.b.ya...@gmail.com:
I don't think global operators is good idea since it can make a script very
complex and you'll have to learn many operators in case the one who wrote it
decided to make it operator driven
On the other hand: If those operators aren't global, then they are
local. I wouldn't like that much more, because inside your project
you will then never know, if and how an operator is currently working.
Much more confusion.
But I wouldn't like to see this operator-stuff using in a normal
context, in normal PHP-scripts. (What's normal?)
I see those operators in a very limited context, e.g. when you create
output (use PHP as template-engine), then they could be extremly
helpful. Always and alyways repeating things, which can't be made
shorter. For example checking the rights of a user:
set_operator_handler('r', function ($user, $current) {
if (!$userrRights-userHasRights($username, $current)) {
throw userRightsException()
}
}
and in the code:
try {
$user ?r: $current;
} catch
Ugly? Yes!!! Very! But that's wanted, because - as said - in very
special context. [But really? You can read the code as: Has the user
the rights for current?]
In the end this is a design-decision. I wouldn't recomend this for the
normal work (as shown above) and I think the said should be part of
the documentation - if it is really implemented. But I think in some
very special contexts this could be really helpful.
However, if we're talking about operators, I do think that adding operator
override option (for the regular operators, such as +, -, * etc.) will be
great for OOP - but that's a different topic.
Existing operators shouldn't be changeable. My suggestion is the
PHP-way of operator driven development for a very special problem,
which is making very repeating but complex things very short, nothing
else. :)
Or in other words: In detail it's great, but in general it's a very
bad idea. :) That's just wanted and if you think you must use it, then
you should have a good reason.
--
Alex Aulbach
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
On 07/24/2012 10:01 AM, Nikita Popov wrote: Another, separate point against finally is that in PHP (unlike many other languages) most (all?) built-in resources clean up after themselves. So if you open a file you don't have to worry about closing it again. It'll do that all by itself as soon as it goes out of scope. The same applies to database handles, etc. As PHP uses refcount based garbage collection the resource is actually cleaned up right away, not just at the next GC run (which could be problematic if you open up many files in a row). Which is the argument for why finally doesn't need to worry about the fatal-error case. Most resources are cleaned up on a fatal already, including your lock example, so it isn't an issue. finally is exception-level for intra-app cleanup, not for request shutdown cleanup. We already have shutdown functions for that case. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
On Tue, Jul 24, 2012 at 6:20 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 07/24/2012 10:01 AM, Nikita Popov wrote:
Another, separate point against finally is that in PHP (unlike many
other languages) most (all?) built-in resources clean up after
themselves. So if you open a file you don't have to worry about
closing it again. It'll do that all by itself as soon as it goes out
of scope. The same applies to database handles, etc. As PHP uses
refcount based garbage collection the resource is actually cleaned up
right away, not just at the next GC run (which could be problematic if
you open up many files in a row).
Which is the argument for why finally doesn't need to worry about the
fatal-error case. Most resources are cleaned up on a fatal already,
including your lock example, so it isn't an issue. finally is
exception-level for intra-app cleanup, not for request shutdown cleanup.
We already have shutdown functions for that case.
Exactly what I've been thinking.
If people are already doing die() in their code, they already don't
care about manually freeing up resources and will let php do its
shutdown process as normal.
I think existing concerns about php's resource freeing upon fatal
errors have been accidentally merged with the finally{} proposal,
which shouldn't be looking to change how things work, but provide an
additional block for further control.
I have had to workaround stuff in my PHP apps because of a lack of
finally{} block, and I hope it makes its way into the next iteration.
Thanks,
Paul.
-Rasmus
--
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] [RFC] Supports 'finally' keyword for PHP exceptions
On Tue, Jul 24, 2012 at 7:25 PM, Paul Dragoonis dragoo...@gmail.com wrote:
I have had to workaround stuff in my PHP apps because of a lack of
finally{} block, and I hope it makes its way into the next iteration.
I think it would add a lot to this discussion if you could show us
what real-life use case you have there that desperately needs
try/finally support. That would probably be a lot more helpful in
understanding the issue than just looking at dummy try/finally blocks
:)
Nikita
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
Hi! In particular this means that... ... if a die() is execute somewhere in the try clause (or a called function) the finally clause must still be run. ... if a parse error or other fatal error occurs in the try clause (or called function) the finally clause must still be run. ... if the user interrupts the process the finally clause must still be run. No I don't think so. finally clause is used to clean up resources allocated/initialized by the code inside try clause. All the above functions will terminate the script and thus all the resources that were allocated will be freed. If you so something more persistent, then a) use shutdown functions b) know that the script can be killed at any moment anyway, so PHP can not guarantee you anything. I don't see how finally ever implied it would be called on die(). Basically this requires that all of the actions that are currently fatal need to be converted to exceptions. E.g. Python has special SystemExit and KeyboardInterrupt exceptions, as well as SyntaxError and so on. So basically this requires that PHP will be converted to Python. ;) I'd almost write an RFC but then I remembered somebody already wrote Python! :) -- 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: Generators in PHP
2012/7/23 Sara Golemon poll...@php.net: Curious if you could expand on that. Generators are iterators, so not sure what you're asking for. It's the point which is unlogical for me. Maybe it's a question. If the generator is an object with the implementation of an iterator, why do we need to have it as _function_? -- Alex Aulbach -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
On 24/07/12 18:31, Stas Malyshev wrote: Hi! In particular this means that... ... if a die() is execute somewhere in the try clause (or a called function) the finally clause must still be run. ... if a parse error or other fatal error occurs in the try clause (or called function) the finally clause must still be run. ... if the user interrupts the process the finally clause must still be run. No I don't think so. finally clause is used to clean up resources allocated/initialized by the code inside try clause. All the above functions will terminate the script and thus all the resources that were allocated will be freed. If you so something more persistent, then a) use shutdown functions b) know that the script can be killed at any moment anyway, so PHP can not guarantee you anything. I don't see how finally ever implied it would be called on die(). Basically this requires that all of the actions that are currently fatal need to be converted to exceptions. E.g. Python has special SystemExit and KeyboardInterrupt exceptions, as well as SyntaxError and so on. So basically this requires that PHP will be converted to Python. ;) I'd almost write an RFC but then I remembered somebody already wrote Python! :) PHP risks losing some of its uniqueness to fixing things, unfortunately. But losing bad features and moving forward is good, right? -- Andrew Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Generators in PHP
On 24/07/12 18:34, Alex Aulbach wrote: 2012/7/23 Sara Golemon poll...@php.net: Curious if you could expand on that. Generators are iterators, so not sure what you're asking for. It's the point which is unlogical for me. Maybe it's a question. If the generator is an object with the implementation of an iterator, why do we need to have it as _function_? Much easier to make an iterator with a function than as a class. -- Andrew Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
Hi! PHP risks losing some of its uniqueness to fixing things, unfortunately. But losing bad features and moving forward is good, right? I'm not sure what you are talking about here, but I'm sure I can not accept argument Python does it this way, so we must do it exactly the same way even if we have to rewrite whole engine and change whole approach of how things done in PHP. If you want exactly what Python does, you always have Python. It's fine to look into what Python does, but how it fits PHP and uses cases of the *PHP* users should always come first, and implementation details of how Python or any other language does things can be a guidance, but never should override this. So if Python does finally in certain way, fine, but it's no no way by itself defines how PHP should do it. -- 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: Generators in PHP
On 24 ביול 2012, at 20:35, Andrew Faulds wrote: On 24/07/12 18:34, Alex Aulbach wrote: 2012/7/23 Sara Golemon poll...@php.net: Curious if you could expand on that. Generators are iterators, so not sure what you're asking for. It's the point which is unlogical for me. Maybe it's a question. If the generator is an object with the implementation of an iterator, why do we need to have it as _function_? Much easier to make an iterator with a function than as a class. -- Andrew Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php I agree, implementing a class only for iterator may be pain sometimes, and functions is much better - especially when 5.3 got the anonymous functions, so we can even use the generators for iterator functions in class methods which can be great. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
On 24/07/12 18:38, Stas Malyshev wrote: Hi! PHP risks losing some of its uniqueness to fixing things, unfortunately. But losing bad features and moving forward is good, right? I'm not sure what you are talking about here, but I'm sure I can not accept argument Python does it this way, so we must do it exactly the same way even if we have to rewrite whole engine and change whole approach of how things done in PHP. If you want exactly what Python does, you always have Python. It's fine to look into what Python does, but how it fits PHP and uses cases of the *PHP* users should always come first, and implementation details of how Python or any other language does things can be a guidance, but never should override this. So if Python does finally in certain way, fine, but it's no no way by itself defines how PHP should do it. What? I'm not suggesting PHP do things because Python does them. I'm just saying that 1) keeping things because they've always been done one way is not a good reason to keep them, and 2) just because Python does the same or a similar thing, does not mean PHP is turning into Python. -- Andrew Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
On 7/24/12 4:20 AM, Laruence wrote: Hi: As the previous threads disscussed, I make a implemention. here is the RFC: https://wiki.php.net/rfc/finally I'm not seeing tests for the following situations: 1. Return from catch block. 2. Another try/catch block inside finally block. 3. Multiple nested functions with finally blocks. 4. Exception thrown in catch block. Could you add those? -- 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] Implicit isset in ternary operator
On 24 ביול 2012, at 20:15, Alex Aulbach wrote:
2012/7/24 Yahav Gindi Bar g.b.ya...@gmail.com:
I don't think global operators is good idea since it can make a script very
complex and you'll have to learn many operators in case the one who wrote it
decided to make it operator driven
On the other hand: If those operators aren't global, then they are
local. I wouldn't like that much more, because inside your project
you will then never know, if and how an operator is currently working.
Much more confusion.
But I wouldn't like to see this operator-stuff using in a normal
context, in normal PHP-scripts. (What's normal?)
I see those operators in a very limited context, e.g. when you create
output (use PHP as template-engine), then they could be extremly
helpful. Always and alyways repeating things, which can't be made
shorter. For example checking the rights of a user:
set_operator_handler('r', function ($user, $current) {
if (!$userrRights-userHasRights($username, $current)) {
throw userRightsException()
}
}
and in the code:
try {
$user ?r: $current;
} catch
Ugly? Yes!!! Very! But that's wanted, because - as said - in very
special context. [But really? You can read the code as: Has the user
the rights for current?]
In the end this is a design-decision. I wouldn't recomend this for the
normal work (as shown above) and I think the said should be part of
the documentation - if it is really implemented. But I think in some
very special contexts this could be really helpful.
Yeah, that's a design decision, but its important because that's one of the PHP
greatest things - the code is very nice and readable, and it's kind of sad to
ruin it...
I didn't thought about template engines - I agree, it'll be great there, but
does a language syntax need to be defined only for a specific cases like
template engine?
However, if we're talking about operators, I do think that adding operator
override option (for the regular operators, such as +, -, * etc.) will be
great for OOP - but that's a different topic.
Existing operators shouldn't be changeable. My suggestion is the
PHP-way of operator driven development for a very special problem,
which is making very repeating but complex things very short, nothing
else. :)
Or in other words: In detail it's great, but in general it's a very
bad idea. :) That's just wanted and if you think you must use it, then
you should have a good reason.
--
Alex Aulbach
If the programmers will follow your guidelines and use this operators only for
some unique and rare cases - I strongly support that idea, but I'm afraid from
programmers who'll make their program full of operators which makes it
unreadable by other programers...
I think that operators overriding should be implemented in a class scope (only
for object with object interaction, such as (merge operation): $mergedMember =
$member1 + $member2; or for roles permission concat - $memberRule = $adminRule
- $editorRule)
But that's a different topic from the suggested feature...
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Implicit isset in ternary operator
My feeling is that either more complex expressions for operators with an implicit isset or !empty shouldn't work, or that they should cause notices. That's exactly why I think we're going in the wrong direction by speaking of an alternate ternary operator. You're saying the basic ternary is (expr1) ? (expr2) : (expr3) But the only notice-free alternate is (var) ?? (expr2) : (expr3) This alternate is just going to cause confusion as it has a different, more limited signature. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Generators in PHP
2012/7/24 Andrew Faulds a...@ajf.me: Much easier to make an iterator with a function than as a class. 2012/7/24 Yahav Gindi Bar g.b.ya...@gmail.com: I agree, implementing a class only for iterator may be pain sometimes, and functions is much better - especially when 5.3 got the anonymous functions, so we can even use the generators for iterator functions in class methods which can be great. Ok, why not call it iterator or generator or huffpuff instead of function? It's just the naming, which disturbs me, because a function is something which is, when called once finished once. I don't like mathematics, but that is one of the definition of a function: http://en.wikipedia.org/wiki/Function_%28mathematics%29 each input is related to exactly one output Couldn't be so complicated to introduce a new name for that, or? -- Alex Aulbach -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Generators in PHP
On 24/07/12 18:56, Alex Aulbach wrote: 2012/7/24 Andrew Faulds a...@ajf.me: Much easier to make an iterator with a function than as a class. 2012/7/24 Yahav Gindi Bar g.b.ya...@gmail.com: I agree, implementing a class only for iterator may be pain sometimes, and functions is much better - especially when 5.3 got the anonymous functions, so we can even use the generators for iterator functions in class methods which can be great. Ok, why not call it iterator or generator or huffpuff instead of function? It's just the naming, which disturbs me, because a function is something which is, when called once finished once. I don't like mathematics, but that is one of the definition of a function: http://en.wikipedia.org/wiki/Function_%28mathematics%29 each input is related to exactly one output Couldn't be so complicated to introduce a new name for that, or? You'll love LISP, I'm sure, or maybe Python's functional subset. But PHP functions usually have side-effects, they aren't strict mathematical functions. So complaining about this is rather pointless. -- Andrew Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Generators in PHP
You could introduce new keyword for generator... even call it generator but why (its kind of design issue...)? if the syntax that one should use in order to implement the generator is just like a function, but using yield keyword in order to return the items to store? As long as I know, most programming languages that uses generators wrap it up in a function, so why shall we introduce new keyword that can confuse programmers? I think using function and returning the value using yield is great... although I'm open to any new nicely-written generator syntax. On 24 ביול 2012, at 20:56, Alex Aulbach wrote: 2012/7/24 Andrew Faulds a...@ajf.me: Much easier to make an iterator with a function than as a class. 2012/7/24 Yahav Gindi Bar g.b.ya...@gmail.com: I agree, implementing a class only for iterator may be pain sometimes, and functions is much better - especially when 5.3 got the anonymous functions, so we can even use the generators for iterator functions in class methods which can be great. Ok, why not call it iterator or generator or huffpuff instead of function? It's just the naming, which disturbs me, because a function is something which is, when called once finished once. I don't like mathematics, but that is one of the definition of a function: http://en.wikipedia.org/wiki/Function_%28mathematics%29 each input is related to exactly one output Couldn't be so complicated to introduce a new name for that, or? -- Alex Aulbach
Re: [PHP-DEV] Re: Generators in PHP
On 24/07/12 19:06, Yahav Gindi Bar wrote: You could introduce new keyword for generator... even call it generator but why (its kind of design issue...)? if the syntax that one should use in order to implement the generator is just like a function, but using yield keyword in order to return the items to store? As long as I know, most programming languages that uses generators wrap it up in a function, so why shall we introduce new keyword that can confuse programmers? I think using function and returning the value using yield is great... although I'm open to any new nicely-written generator syntax. On 24 ביול 2012, at 20:56, Alex Aulbach wrote: 2012/7/24 Andrew Faulds a...@ajf.me: Much easier to make an iterator with a function than as a class. 2012/7/24 Yahav Gindi Bar g.b.ya...@gmail.com: I agree, implementing a class only for iterator may be pain sometimes, and functions is much better - especially when 5.3 got the anonymous functions, so we can even use the generators for iterator functions in class methods which can be great. Ok, why not call it iterator or generator or huffpuff instead of function? It's just the naming, which disturbs me, because a function is something which is, when called once finished once. I don't like mathematics, but that is one of the definition of a function: http://en.wikipedia.org/wiki/Function_%28mathematics%29 each input is related to exactly one output Couldn't be so complicated to introduce a new name for that, or? -- Alex Aulbach And anyway it just depends on your perspective. It's still a function IMO, it doesn't return, it yields. To me it's kinda like having a function in another thread that passes several messages back over its lifetime, and then finally returns. -- Andrew Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Implicit isset in ternary operator
2012/7/24 Yahav Gindi Bar g.b.ya...@gmail.com: Yeah, that's a design decision, but its important because that's one of the PHP greatest things - the code is very nice and readable, and it's kind of sad to ruin it... I didn't thought about template engines - I agree, it'll be great there, but does a language syntax need to be defined only for a specific cases like template engine? It's one of the best things of PHP and the reason, why it was invented. If the programmers will follow your guidelines and use this operators only for some unique and rare cases - I strongly support that idea, but I'm afraid from programmers who'll make their program full of operators which makes it unreadable by other programers... Hhummm, every programming language could be written unreadable. Even PHP. I can say that per sure. :) I think that operators overriding should be implemented in a class scope (only for object with object interaction, such as (merge operation): $mergedMember = $member1 + $member2; or for roles permission concat - $memberRule = $adminRule - $editorRule) But that's a different topic from the suggested feature... Which is a much better idea in general. My suggestion was only for a very special context and should be easier to implement. I currently think, this discussion needs more time, because I begin to forget, for what this is really needed. :) I suggest to (re)think about the real usage-cases... -- Alex Aulbach -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Generators in PHP
2012/7/24 Andrew Faulds a...@ajf.me: But PHP functions usually have side-effects, they aren't strict mathematical functions. Ah, you might mean str_tok()? Are there more, do you have a list? But we're in PHP-programming-context. You write a function in PHP, you call it and it will return once called. I see there no exeption. So complaining about this is rather pointless. I don't complain about the past. I just think now, that if it doesn't behave like a function it shouldn't be called function. A function which returns as an object and is not completed is not a function. And if other languages do so, my argument will be the same. rising finger with epic mimic, fistulous voice We need not to make the same mistake again! :) -- Alex Aulbach -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Proposal namespace importing with from syntax
Hi! from GlobalNamespace\SubSpace\ThirdSace use Class1, Class2 as Alias2, ForthSpace\Class3 as Alias3; I'm not sure it's necessary. If you import a real lot of the classes from the same namespace, just import the parent namespace. And this syntax makes less clear what is the true name of Class2 and also by similarity to python syntax would lead people to think it does the same thing python one does - which it is not. -- 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: Generators in PHP
On 24/07/12 19:32, Alex Aulbach wrote: 2012/7/24 Andrew Faulds a...@ajf.me: But PHP functions usually have side-effects, they aren't strict mathematical functions. Ah, you might mean str_tok()? Are there more, do you have a list? But we're in PHP-programming-context. You write a function in PHP, you call it and it will return once called. I see there no exeption. So complaining about this is rather pointless. I don't complain about the past. I just think now, that if it doesn't behave like a function it shouldn't be called function. A function which returns as an object and is not completed is not a function. And if other languages do so, my argument will be the same. rising finger with epic mimic, fistulous voice We need not to make the same mistake again! :) All the array_* functions have side effects. Most class methods, which are also functions, have side effects. Most of the functions I write have side effects. Much of mysql_* has side effects. PHP is not LISP. -- Andrew Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Generators in PHP
Em Tue, 24 Jul 2012 19:56:46 +0200, Alex Aulbach alex.aulb...@gmail.com
escreveu:
2012/7/24 Andrew Faulds a...@ajf.me:
Much easier to make an iterator with a function than as a class.
2012/7/24 Yahav Gindi Bar g.b.ya...@gmail.com:
I agree, implementing a class only for iterator may be pain sometimes,
and functions is much better - especially when 5.3 got the anonymous
functions, so we can even use the generators for iterator functions in
class methods which can be great.
Ok, why not call it iterator or generator or huffpuff instead of
function? It's just the naming, which disturbs me, because a
function is something which is, when called once finished once. I
don't like mathematics, but that is one of the definition of a
function:
http://en.wikipedia.org/wiki/Function_%28mathematics%29
each input is related to exactly one output
Other have already explained that PHP functions are not strictly
mathematical functions, but generators nevertheless somewhat fit that
description. When you have function foo() { ... yield /* ... */; ... } and
you call foo(), you get the same thing every time: a Generator object. It
so happens that the implementation of that object is inside the body of
the function.
Maybe this helps you reason about the feature.
--
Gustavo Lopes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
Hi! Still my point stands. If fatal errors and die are not handled by finally the feature does not make sense to me. You simply can't do any kind of remotely important cleanup in there (like releasing locks etc). Well, I'm sorry you don't understand it but I think you are too focused on exactly copying what you are accustomed to, and this is not the goal for PHP. I don't know what you mean by important cleanup but if you mean you do some persistent things that absolutely need to be cleaned up by code, I have very bad news for you. PHP is not the language that can do it. PHP script can be terminated at any moment - by the webserver, by the OS, by other means - and that'd be just that, it would cease to exist and no code will be run. finally can not and will not solve this problem. It is not meant to solve this problem. It is meant to solve specific use-case of using temporary resources in a block of code and cleaning them immediately (as opposed to waiting until request-level cleanup). Fortunately, in my many years of working with PHP I don't think I ever saw any case where simple OS functions coupled with more powerful constructs like transactions were not enough to cleanup anything that PHP script could do. Similarly die; is commonly called in code doing header redirects. I think it would be unacceptable to not run cleanup clauses in that case. If you need cleanups on the request level, you already have shutdown functions. Those, btw, aren't guaranteed to run in every case too - there can be situations, albeit rare, that shutdown could fail and thus some cleanup not run (e.g. the process being killed, PHP getting out of memory, etc.). Also, there could be more frequent situation that your shutdown code has a bug which causes it to terminate early. Which btw may be a case with Python code too - unless you wrap every statement in a separate finally clause you have the same issue. Another, separate point against finally is that in PHP (unlike many other languages) most (all?) built-in resources clean up after themselves. So if you open a file you don't have to worry about closing it again. It'll do that all by itself as soon as it goes out You don't have to, but in some cases you better to if you write more than two-liner, since otherwise, while the file does not survive the request, with suitable scope it may linger much longer than you expect. So in some cases having shorter-scope cleanups can be helpful. Of course, you can also do pretty much the same with RAII pattern - so it's not strictly necessary. But may be nice to have. -- 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: Generators in PHP
2012/7/24 Andrew Faulds a...@ajf.me: PHP is not LISP. Hey, I don't want to have LISP. I just want to make complicated things more clear, and it doesn't matter, if something else is right or wrong in the past. It isn't difficult to make a new keyword or something wich disticts it a little bit more for that. -- Alex Aulbach -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: michaelhood
rasmus approved michaelhood account request \o/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Generators in PHP
2012/7/24 Gustavo Lopes glo...@nebm.ist.utl.pt:
When you have function foo() { ... yield /* ... */; ... } and
you call foo(), you get the same thing every time: a Generator object. It so
happens that the implementation of that object is inside the body of the
function.
Hmmm. It's not that I didn't understand it. :)
My thoughts are about usage in practice. Ok, my first argument with
the developer, who overtakes an old project was weak.
What about situations, when developers with different knowlegde work together?
Or when you have programming errors, when you write
function blubb()
{
... yields...
...
... return
}
(you may only see the return).
And many those situations are thinkable, because this kind of PHP
function works so totally different from current.
Maybe this helps you reason about the feature.
Please understand me, it's not that I don't like it or that I couldn't
live with it. It's because I have too much experience what could
happen if new programming features are introduced.
For example: Exceptions in PHP are quite old now. And the concept of
exceptions should be known. But I worked together with programmers
wich produced code like
...
try {
$value = method_which_throws_exceptions();
} catch (...) {
return $value;
}
return $value;
...
And he has it done, although I wrote some example code for him how to
use exceptions in this context!!11!
THAT'S the reality.
We can ignore that, but I just want to make such simple mistakes not
so easy and the afford is worth the results.
You can argue: Those mistakes will always happen. I say Yes, of
course, but if we have the chance to reduce those mistakes we should
do it.
--
Alex Aulbach
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Generators in PHP
On 24/07/12 20:13, Alex Aulbach wrote:
2012/7/24 Gustavo Lopes glo...@nebm.ist.utl.pt:
When you have function foo() { ... yield /* ... */; ... } and
you call foo(), you get the same thing every time: a Generator object. It so
happens that the implementation of that object is inside the body of the
function.
Hmmm. It's not that I didn't understand it. :)
My thoughts are about usage in practice. Ok, my first argument with
the developer, who overtakes an old project was weak.
What about situations, when developers with different knowlegde work together?
Or when you have programming errors, when you write
function blubb()
{
... yields...
...
... return
}
(you may only see the return).
And many those situations are thinkable, because this kind of PHP
function works so totally different from current.
Maybe this helps you reason about the feature.
Please understand me, it's not that I don't like it or that I couldn't
live with it. It's because I have too much experience what could
happen if new programming features are introduced.
For example: Exceptions in PHP are quite old now. And the concept of
exceptions should be known. But I worked together with programmers
wich produced code like
...
try {
$value = method_which_throws_exceptions();
} catch (...) {
return $value;
}
return $value;
...
And he has it done, although I wrote some example code for him how to
use exceptions in this context!!11!
THAT'S the reality.
We can ignore that, but I just want to make such simple mistakes not
so easy and the afford is worth the results.
You can argue: Those mistakes will always happen. I say Yes, of
course, but if we have the chance to reduce those mistakes we should
do it.
It's fairly obvious from context these aren't ordinary functions, IMO.
And anyway, what could possibly go wrong? Is there any incorrect but
non-fatal or warning-generating way you could use them?
--
Andrew Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] del php-src: .travis.yml LICENSE Makefile.gcov NEWS README.md UPGRADING UPGRADING.INTERNALS Zend/tests/bug18556.phpt Zend/tests/bug60738.phpt Zend/tests/bug61681.phpt Zend/test
Hi, for some reason master was merged into the PHP-5.4 branch. I undid this change in the repo. If you pulled in between your next pull should result in an error. Use git reset --hard origin/PHP-5.4 to reset your local checkout to the current version on the server. johannes On Wed, 2012-07-25 at 00:15 +, Johannes Schlüter wrote: Branch: PHP-5.4 Deleted commits count: 2298 User: Johannes Schlüter johan...@php.net Wed, 25 Jul 2012 00:15:30 + -- PHP CVS Mailing List (http://www.php.net/) 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: [PHP-CVS] del php-src: .travis.yml LICENSE Makefile.gcov NEWS README.md UPGRADING UPGRADING.INTERNALS Zend/tests/bug18556.phpt Zend/tests/bug60738.phpt Zend/tests/bug61681.phpt Zend/
Use git reset --hard origin/PHP-5.4 to reset your local checkout to the current version on the server. It should be noted that when you `reset --hard`, you'll lose local changes (including branch commits, except in the reflog). You'll probably want to stash first, reset, then stash pop (or branch locally, merge, checkout 5.4, reset, then cherry-pick (or maybe merge)). Sorry for the noise if this is already widely known, but since PHP is relatively new to the world of git, I thought it was worth mentioning. S
Re: [PHP-DEV] Re: [PHP-CVS] del php-src: .travis.yml LICENSE Makefile.gcov NEWS README.md UPGRADING UPGRADING.INTERNALS Zend/tests/bug18556.phpt Zend/tests/bug60738.phpt Zend/tests/bug61681.phpt Zend/
On Tue, 2012-07-24 at 20:34 -0400, Sean Coates wrote: Use git reset --hard origin/PHP-5.4 to reset your local checkout to the current version on the server. It should be noted that when you `reset --hard`, you'll lose local changes (including branch commits, except in the reflog). You'll probably want to stash first, reset, then stash pop (or branch locally, merge, checkout 5.4, reset, then cherry-pick (or maybe merge)). Sorry for the noise if this is already widely known, but since PHP is relatively new to the world of git, I thought it was worth mentioning. Thanks for the advise! I hope nobody was affected as we had the issue for less than an hour. For reference: The 5.4 with the invalid commit is backed up at https://github.com/johannes/php-src/commits/php-5.4-messup2 The bad commit was 8ad868 there, looks innocent but is quite a big merge. I wonder if anybody can suggest a way to detect such commits automatically so we can catch them. `git diff` and others show nothing of relevance. To undo the commit I took the following steps: $ git checkout PHP-5.4# Get a clean tree including the bad # commit $ git reset --hard 5f224412fa689 # This is the last good commit # before 8ad868 $ git push -f origin PHP-5.4 # Overwrite newer versions on the # server. Right now only I can do that # (see my recent commit to karma.git) johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
发自我的 iPad 在 2012-7-25，1:50，Stas Malyshev smalys...@sugarcrm.com 写道： On 7/24/12 4:20 AM, Laruence wrote: Hi: As the previous threads disscussed, I make a implemention. here is the RFC: https://wiki.php.net/rfc/finally I'm not seeing tests for the following situations: 1. Return from catch block. 2. Another try/catch block inside finally block. 3. Multiple nested functions with finally blocks. 4. Exception thrown in catch block. They are in the test scripts in commits, But sure, I should note them out Thanks Could you add those? -- 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: Generators in PHP
Or when you have programming errors, when you write
function blubb()
{
... yields...
...
... return
}
(you may only see the return).
But that's okay, because PHP *does* see both, and it tells you yield may
not be used with return in a lovely little parser error. Some developers
consider this a useful hint.
-Sara
[PHP-DEV] 回复： [PHP-DEV] [RFC] Proposal namespace importing with from syntax
Hi Stas,
在 2012年7月25日星期三，上午2:33，Stas Malyshev 写道：
Hi!
from GlobalNamespace\SubSpace\ThirdSace use Class1, Class2 as Alias2,
ForthSpace\Class3 as Alias3;
I'm not sure it's necessary. If you import a real lot of the classes
from the same namespace, just import the parent namespace. And this
No, we can not import namespace directly for now :
?php
namespace A {
class B {}
}
namespace {
use A;
var_dump(new B());
}
Warning: The use statement with non-compound name 'A' has no effect in
/Users/reeze/Opensource/php-test/php-src-master/a.php on line 7
if we wan to archive the goal of import anything. the only way is to declare
the current namespace
as the parent namespace we want to import from, eg:
?php
namespace Zend {
class B {}
}
namespace *Zend* {
var_dump(new B());
}
but this is not preferred for use code declared as the library we used.
syntax makes less clear what is the true name of Class2 and also by
similarity to python syntax would lead people to think it does the same
thing python one does - which it is not.
Sorry, I didn't make myself clear. the example I posted is not correct. It
didn't have to alias the imported classes.
'use' statement can alias the imported class too, the proposed 'from xx use yy'
is almost
the same as 'use'
The correct example should be:
?php
// if we don't want to duplicated then the follow could be
use GlobalNamespace\SubSpace\ThirdSpace\Class1;
use GlobalNamespace\SubSpace\ThirdSpace\Class2;
use GlobalNamespace\SubSpace\ThirdSpace\Class3;
// reduced to
from GlobalNamespace\SubSpace\ThirdSace use Class1, Class2, Class3 ;
?
and if we need alias we could：
?php
// reduce
use GlobalNamespace\SubSpace\ThirdSpace\Class1;
use GlobalNamespace\SubSpace\ThirdSpace\Class2 as Alias2;
use GlobalNamespace\SubSpace\ThirdSpace\ForthSpace\Class3 as Alias3;
// to
from GlobalNamespace\SubSpace\ThirdSace use Class1, Class2 as Alias2,
ForthSpace\Class3 as Alias3;
?
Thanks stas.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Re: [PHP-DEV] Re: Generators in PHP
On 24/07/12 19:32, Alex Aulbach wrote: 2012/7/24 Andrew Faulds a...@ajf.me: But PHP functions usually have side-effects, they aren't strict mathematical functions. Ah, you might mean str_tok()? Are there more, do you have a list? But we're in PHP-programming-context. You write a function in PHP, you call it and it will return once called. I see there no exeption. So complaining about this is rather pointless. I don't complain about the past. I just think now, that if it doesn't behave like a function it shouldn't be called function. A function which returns as an object and is not completed is not a function. And if other languages do so, my argument will be the same. rising finger with epic mimic, fistulous voice We need not to make the same mistake again! :) All the array_* functions have side effects. Most class methods, which are also functions, have side effects. Most of the functions I write have side effects. Much of mysql_* has side effects. PHP is not LISP. LISP has side effects. -- Andrew Faulds http://ajf.me/ -- Trying to solve cultural problems with the programming language rarely works. I don't think it contributes much to how well a developer will learn the use of generators with whether we use function or another keyword. With that said I believe that's the point of a discussion phase and I'd like to offer that we're free to implement it how we want. PHP made implementation mistakes in the past that led to awkward behavior (like objects passed by value in PHP4), but that's never stopped things from moving forward and offering up useful features that users want. I think putting the technical details aside the engine can aid a developer in distinguishing between spotting unintended side effects and preventing disastrous consequences. You have similar issues with developers that try to execute database queries while there are buffered results or developers that inadvertently write infinite loops. There are enough safeguards in place to help avoid such nuances. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Internal iteration API
On 07/24/2012 03:52 AM, jpauli wrote: On Sat, Jul 14, 2012 at 2:35 AM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! So, I've not been inside the engine so in practice this may make no sense at all, but what about looking at it the other way around? Vis, instead of making objects more and more like arrays, make arrays an object that happens to implement ArrayAccess, Iterator, and whatever That'd be very nice idea if we were implementing new PHP. I think the fact that arrays are not objects in PHP is a source of many problems. However, right now it probably won't be possible to do it without breaking BC in many places dealing with array copy/assignment/passing semantics. I'd then say : let's keep that idea somewhere to implement it in a new major PHP version. Anyway, there will come a time where we will be developing for PHP6 (or PHP next Major if you prefer), and I think we should use this gap to break BC and add new cool ideas like this one, we seem all to agree with. Julien.P Agreed. We survived Objects becoming, er, Objects in PHP 5.0. Arrays changing would be a major version change, but if the benefits are enough, we could survive that, too. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] del php-src: .travis.yml LICENSE Makefile.gcov NEWS README.md UPGRADING UPGRADING.INTERNALS Zend/tests/bug18556.phpt Zend/tests/bug60738.phpt Zend/tests/bug61681.phpt Zend/
Hi! I wonder if anybody can suggest a way to detect such commits automatically so we can catch them. `git diff` and others show nothing of relevance. We could get some commit that is only in master (like NEWS edits, for example) and check for it - if it's ever pushed into 5.4 that's trouble. This is of course a special master/5.4 hack but should work I think... -- 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: 回复： [PHP-DEV] [RFC] Proposal namespace importing with from syntax
Hi!
No, we can not import namespace directly for now :
Of course you can. You just missing on what namespace import means in
PHP, it's not like Java (though a bit like Python).
?php
namespace A {
class B {}
}
namespace {
use A;
var_dump(new B());
}
use A is a no-op, just as the warnings tell you. You can just write A\B.
It's only 2 characters more. If your A is longer, then you can alias it
to something shorter.
and if we need alias we could：
?php
// reduce
use GlobalNamespace\SubSpace\ThirdSpace\Class1;
use GlobalNamespace\SubSpace\ThirdSpace\Class2 as Alias2;
use GlobalNamespace\SubSpace\ThirdSpace\ForthSpace\Class3 as Alias3;
You could just do
use GlobalNamespace\SubSpace\ThirdSpace as Spc;
$a = new Spc\Class1();
--
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: 回复： [PHP-DEV] [RFC] Proposal namespace importing with from syntax
Hi:
is there any really usage? I didn't see before. I don't think every
python feature is proper for PHP. PHP is not python.
-1 on this RFC
+1 for Stas
and one more thing, BC break.
there are many ORM or DB warpper libraries defines `from` method, like:
$db-select()-from();
thanks
On Wed, Jul 25, 2012 at 1:22 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
No, we can not import namespace directly for now :
Of course you can. You just missing on what namespace import means in
PHP, it's not like Java (though a bit like Python).
?php
namespace A {
class B {}
}
namespace {
use A;
var_dump(new B());
}
use A is a no-op, just as the warnings tell you. You can just write A\B.
It's only 2 characters more. If your A is longer, then you can alias it
to something shorter.
and if we need alias we could：
?php
// reduce
use GlobalNamespace\SubSpace\ThirdSpace\Class1;
use GlobalNamespace\SubSpace\ThirdSpace\Class2 as Alias2;
use GlobalNamespace\SubSpace\ThirdSpace\ForthSpace\Class3 as Alias3;
You could just do
use GlobalNamespace\SubSpace\ThirdSpace as Spc;
$a = new Spc\Class1();
--
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
--
Laruence Xinchen Hui
http://www.laruence.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
