Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...)
Just a minor question, Derick. If you care about phpdbg, why are you only dropping any comment about it by the time it got into php-src repo? It’s known that all the development currently (except for master, but that just was a merge and then a pure rewrite on top of that merge, nothing related to the protocol) is going on in krakjoe/phpdbg github repo. There was now an xml-protocol branch for three weeks before it got merged into krakjoe/phpdbg#master. You had vast time to notice it and complain before, if you’d really have cared. To reply to your question: why not use another debugger protocol? I had first really looked for other protocols, but none really fitted our needs. There was just DBGp which approximated our needs. At the beginning I had tried to implement a slightly modified variant of DBGp, but it accumulated minor differences here and there… And that then doesn’t make much sense again. That was the time where we decided to implement our own protocol. Before you ask, an incomplete list of such differences: - connecting: phpdbg is the server, not the client (as opposed to what DBGp requires) - no need for the proxy thing - breakpoints: we have an opline-wise breaking (I have no idea, but maybe an IDE might want to break before the fcall is done) doesn’t fit into current list of attributes - It is under some circumstances possible to not be able to provide a full response (e.g. we’ve done a hard interrupt (that means, instant, asynchronous interrupt, even when engine is in control of it)) - DBGp provides no mechanism to handle it - stdout, stderr commands also don’t really work with phpdbg — it’s always redirect mode - … Further, but not the main reason why we didn’t use it, we’d have had to implement another commands lexer, parser and interpreter alongside our current commands. DBGp commands aren’t exactly user-friendly; they’re designed to be used by a machine. It made the whole implementation a lot easier to not use a fork of DBGp adapted to our needs. (at the time we realized we couldn’t really use DBGp) So, we’ve introduced a new protocol. I didn’t try to make a protocol compatible with any future debugger; each debugger has a bit his special needs and you cannot suit everyones needs. Bob p.s.: And yes, PhpStorm was involved, a huge thanks to them for the precious feedback they’ve given me for the last three weeks. Am 25.10.2014 um 11:45 schrieb Pierre Joye pierre@gmail.com: On Sat, Oct 25, 2014 at 4:39 PM, Joe Watkins pthre...@pthreads.org wrote: Pierre, I wasn't involved in the conversations during it's development very much. You will have to wait for bob or someone from the phpstorm team to fill in the blanks. Suffice to say that they found a reason to work on a new protocol, details I don't know. It had it's own remote protocol when it was merged, but it turned out to be pretty useless for those people interested in using it remotely. This is only a development of that original feature. I of course recognize that we are in some sense representative of the PHP project, however, we are talking about words like awesomesauce, not profanity, or anything offensive whatever. Bob done all the work on this, in record time. It's totally crappy that he'll wake up today to this nonsense, he should be feeling pleased with himself. He worked very hard on it. Cannot agree more. I very much like phpdbg and really appreciate all the aweome work you guys have put in it. I am only trying to understand this whole protocol thing, in the most objecitve way :). I did not know phpstorm was involved either, that makes me feel better about it. They know very well what is needed and have a very large experience in this area. I am convinced things will be clear soon :) -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...)
Am 25.10.2014 um 17:37 schrieb Sebastian Bergmann sebast...@php.net: Am 25.10.2014 um 13:00 schrieb Weinand Bob: It’s known that all the development currently is going on in krakjoe/phpdbg github repo. Why is that, exactly? I find it weird that something that is shipped with official releases of PHP is not developed alongside the rest of PHP. That’s because all the work originated in the krakjoe/phpdbg repo, even before it was pushed to php-src. Also, it contains code which makes it compatible with PHP 5.4+. If it’d be in the main repo, users with lower PHP versions couldn’t use it at all. By the way, phpdbg in PHP 7 isn’t handled by that repo anymore, it’s directly in master. But new features will still have to be merged up (except if it are PHP 7-only features) as long as PHP 5 branch has still one active (non-sec-fixes-only) branch. Bob -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Safe Casting Functions
So, what exactly changes here if we have a second parameter or just return null
by default?
It doesn’t make any difference, it’s just another way to write it:
to_int($a, $default)
or
to_int($a) ?? $default
Also, if you want exceptions, you always can wrap a userland function around it
— but I’d rather not wrap an userland function around something throwing an
exception… inefficient and weird.
Thanks,
Bob
Am 22.10.2014 um 12:27 schrieb Dmitry Stogov dmi...@zend.com:
null or false return value would make these functions not really
useful, because they won't guarantee to return desired type.
printf(%d\n, to_int(abcd)); // will print 0
The only reliable option to support wrong input is exceptions.
On the other hand, exceptions maybe difficult to use or inefficient.
We may avoid exceptions throwing, if provide a default value:
function to_int(mixed $a , int $default_value = null): int;
function to_double(mixed $a , double $default_value = null): double;
function to_string(mixed $a, string $default_value = null): string;
Thanks. Dmitry.
On Wed, Oct 22, 2014 at 12:37 PM, Bob Weinand bobw...@hotmail.com wrote:
I know we have that already discussed a lot now, but I’d like to expose my
points on the return value here:
I imagine code like (supposing that we ever will have scalar typehints):
function acceptsInt (int $i = null) {
if ($i === null) {
$i = 2 /* default value */;
}
/* do something with $i */
}
When we return false:
acceptInt(($tmp = to_int($_GET[userinput])) === false ? null : $tmp);
When we throw an exception:
try {
acceptInt(to_int($_GET[userinput]));
} catch (CastingException $e) {
acceptInt(null);
}
When we just return null:
acceptInt(to_int($_GET[userinput]));
Also, when we want to pass a default value defined outside of the
function, it’s a lot easier now with the coalesce operator:
acceptInt(to_int($_GET[userinput“]) ?? 2 /* default value */);
Also, independently of possible scalar typehints:
Generally exceptions are also a bad idea as the casts probably will be
used on external input and exceptions are **not** a way to handle malformed
user input. Really not.
Furthermore, false is a bad idea in the same sense (if we get scalar type
hints once), because people then might just catch the EngineException…
Also, null means no value; that’s exactly what we need. If the
to_{type}() functions cannot return a meaningful value, just return no
value, that means null. And not false, which is a real value.
That’s why I strongly feel that null is the only true thing to return here.
Thanks,
Bob
Am 21.10.2014 um 00:57 schrieb Andrea Faulds a...@ajf.me:
Good evening,
I am presenting a new RFC to add a set of three functions to do
validated casts for scalar types:
https://wiki.php.net/rfc/safe_cast
Please read it.
Thanks!
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Safe Casting Functions
If we really want an integer at all price we just can use a simple (int) cast.
That’s AFAIK not the point of this RFC.
And at that point where we can add a default as second parameter, we also just
can use NULL with ??. The latter is at the same time more powerful and less
restrictive.
Also, with a second parameter, we don’t have any possibility to check if the
conversion was successful or if the fallback was used.
Bob
Am 22.10.2014 um 14:49 schrieb Dmitry Stogov dmi...@zend.com:
for me it's weird that to_int() that must return int may return not int.
NULL with ?? seems better than FALSE :)
but if we talk about safety, we should be able to relay on to_int() return
value without additional checks.
Thanks. Dmitry.
On Wed, Oct 22, 2014 at 4:35 PM, Weinand Bob bobw...@hotmail.com
mailto:bobw...@hotmail.com wrote:
So, what exactly changes here if we have a second parameter or just return
null by default?
It doesn’t make any difference, it’s just another way to write it:
to_int($a, $default)
or
to_int($a) ?? $default
Also, if you want exceptions, you always can wrap a userland function around
it — but I’d rather not wrap an userland function around something throwing
an exception… inefficient and weird.
Thanks,
Bob
Am 22.10.2014 um 12:27 schrieb Dmitry Stogov dmi...@zend.com
mailto:dmi...@zend.com:
null or false return value would make these functions not really
useful, because they won't guarantee to return desired type.
printf(%d\n, to_int(abcd)); // will print 0
The only reliable option to support wrong input is exceptions.
On the other hand, exceptions maybe difficult to use or inefficient.
We may avoid exceptions throwing, if provide a default value:
function to_int(mixed $a , int $default_value = null): int;
function to_double(mixed $a , double $default_value = null): double;
function to_string(mixed $a, string $default_value = null): string;
Thanks. Dmitry.
On Wed, Oct 22, 2014 at 12:37 PM, Bob Weinand bobw...@hotmail.com
mailto:bobw...@hotmail.com wrote:
I know we have that already discussed a lot now, but I’d like to expose my
points on the return value here:
I imagine code like (supposing that we ever will have scalar typehints):
function acceptsInt (int $i = null) {
if ($i === null) {
$i = 2 /* default value */;
}
/* do something with $i */
}
When we return false:
acceptInt(($tmp = to_int($_GET[userinput])) === false ? null : $tmp);
When we throw an exception:
try {
acceptInt(to_int($_GET[userinput]));
} catch (CastingException $e) {
acceptInt(null);
}
When we just return null:
acceptInt(to_int($_GET[userinput]));
Also, when we want to pass a default value defined outside of the
function, it’s a lot easier now with the coalesce operator:
acceptInt(to_int($_GET[userinput“]) ?? 2 /* default value */);
Also, independently of possible scalar typehints:
Generally exceptions are also a bad idea as the casts probably will be
used on external input and exceptions are **not** a way to handle malformed
user input. Really not.
Furthermore, false is a bad idea in the same sense (if we get scalar type
hints once), because people then might just catch the EngineException…
Also, null means no value; that’s exactly what we need. If the
to_{type}() functions cannot return a meaningful value, just return no
value, that means null. And not false, which is a real value.
That’s why I strongly feel that null is the only true thing to return here.
Thanks,
Bob
Am 21.10.2014 um 00:57 schrieb Andrea Faulds a...@ajf.me
mailto:a...@ajf.me:
Good evening,
I am presenting a new RFC to add a set of three functions to do
validated casts for scalar types:
https://wiki.php.net/rfc/safe_cast https://wiki.php.net/rfc/safe_cast
Please read it.
Thanks!
--
Andrea Faulds
http://ajf.me/ http://ajf.me/
