Re: [PHP-DEV] Re: Only variables can be passed by reference
Hi Rowan, On Fri, Dec 5, 2014 at 6:12 PM, Rowan Collins wrote: > The author of function f1() presumably designed it to apply some change to > $v, rather than executing only for its side effects and return value. If > the caller wants to ignore this design, they can, but they are not using > the function as it was designed. If they pass a function return straight > into it, they have no way of capturing the change to $v which the author > intended them to see. The value supplied to f1() is return value. In languages, there are literal, constant and variable. Return value is variable. It's better to keep basic rule. IMHO. $top = array_pop(f2()); is better than $v = f2(); $top = array_pop($v); Is there anyone who likes latter? Are there any other languages behave like PHP? Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Zend Engine 3
> On 24 Nov 2014, at 00:10, Andrea Faulds wrote: > > Good evening, > > Since phpng, int64, and perhaps other future changes in PHP 7 are a pretty > big change, I think we ought to bump the major version number of the Zend > Engine, from Zend Engine 2 to Zend Engine 3. > > I have a pull request open which would do this, although it needs updating to > correct extensions checking for ZEND_ENGINE_2: > https://github.com/php/php-src/pull/829 > > Are there any objections to the idea? I realise work on the engine isn’t > done, but that doesn’t mean we can’t name the new version. After all, we’ve > named PHP 7, and it doesn’t exist yet, either. Some changes were made and reviewed, and the pull request has been merged. PHP 7 shall ship with Zend Engine 3! \o/ https://github.com/php/php-src/commit/150dc69d6eee35738f505e925ee664c02060196d -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Comparison chain
On Fri, Dec 5, 2014 at 3:47 PM, Andrea Faulds wrote: > > > On 5 Dec 2014, at 14:36, Дмитрий wrote: > > > > Hi! > > > > I followed by https://wiki.php.net/rfc/howto and I would like to > propose a concept "comparison chain" to implementing to future PHP versions. > > It would be very usable if PHP can do that in python-style. > > > > Thank for your attension! > > Are you saying to allow (1 < x < 2) etc.? That would be nice, although > it’s a backwards-compatibility break as currently (1 < x < 2) would do > something different, as would, say, ($x == $y == $z). > Comparisons are non-associative in PHP [1], so something like $x == $y == $z is currently invalid code. As such this would not break compatibility. Nikita [1]: http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_language_parser.y#81
Re: [PHP-DEV] Comparison chain
Andrea Faulds wrote on 05/12/2014 14:47: On 5 Dec 2014, at 14:36, Дмитрий wrote: Hi! I followed by https://wiki.php.net/rfc/howto and I would like to propose a concept "comparison chain" to implementing to future PHP versions. It would be very usable if PHP can do that in python-style. Thank for your attension! Are you saying to allow (1 < x < 2) etc.? That would be nice, although it’s a backwards-compatibility break as currently (1 < x < 2) would do something different, as would, say, ($x == $y == $z). For those of us that don't know Python, an explanation might be handy. From a quick search, this StackOverflow answer sums it up quite nicely, assuming it's correct: http://stackoverflow.com/a/25753528/157957 So, "$a < $b < $c" would be short-hand for "$a < $b && $b < $c". It would short-circuit in exactly the same way, and be extended to any number of comparison operators. The obvious use case is for maths style "is between" notation, e.g. if ( 10 < $total <= 100 ) Is this correct, a) for Python, and b) for what is suggested for PHP? As Andrea notes, it would be a backwards compatibility, although the chances of anyone deliberately using a boolean as operand to a < or > are unlikely, and that's what's currently implied by $x < $y < $z. Perhaps if == was left out of the mix, so that $x == $y == true would evaluate the same way it does now, that might be a working compromise? Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Question about range comparison
Hi internals, I want to compare the range between two commits of the PHP GitHub. I did the git checkout like this one [1] The problem is that I cannot compare, because in the timeline of commits, it only appears the commits sent by the users, and not the commits that were merged in the branch master. In other words, the timeline only shows the commits sent without rebase, so, if I try the comparison, I will compare two forks of the PHP, and not the PHP branch master with the commits applied. I wonder how I could I do this? Thanks. [1] http://stackoverflow.com/questions/7832770/get-certain-commit-from-github-project -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend language parser improvements
Hi guys, I'd really appreciate some review around the before-mentioned PRs. I have added a new one to the list now: - https://github.com/php/php-src/pull/937 This PR addresses the parsing support for traits to have "extends" and "implements", as they are invalid. There's another one in the oven, which prevents extension developers to create classes that extends traits or interfaces. This is currently supported only for userland classes, but not for Zend API. Cheers, On Wed, Dec 3, 2014 at 8:39 PM, guilhermebla...@gmail.com < guilhermebla...@gmail.com> wrote: > > > On Wed, Dec 3, 2014 at 8:06 PM, Levi Morrison wrote: > >> The parser changes need to be careful reviewed; I don't have time at >> the moment to verify it but I think you unintentionally allowed some >> syntax's that shouldn't be valid because of the addition to >> `inner_statement`. >> > > Shouldn't. I broke down class_declaration_statement into 3 pieces: > class_declaration_statement, interface_declaration_statement and > trait_declaration_statement. > At the end, all I've done is adding the other 2 new rules back to where it > was consumed. > > >> >> Maybe I just looked too quickly. In any case, parser changes should >> always get several people reviewing them. >> > > Agreed. =) > > -- > Guilherme Blanco > MSN: guilhermebla...@hotmail.com > GTalk: guilhermeblanco > Toronto - ON/Canada > -- Guilherme Blanco MSN: guilhermebla...@hotmail.com GTalk: guilhermeblanco Toronto - ON/Canada
[PHP-DEV] libmcrypt: abandonware?
Hi PHP Internals, I've been trying to get in contact with the maintainers of libmcrypt, but every response I've gotten was, "Oh, I haven't been a part of that for years." http://sourceforge.net/projects/mcrypt/files/Libmcrypt/ The last update to libmcrypt was in 2007. There are bug fixes in their issue tracker collecting dust. Is there anyone who knows what happened to the project? Is there anyone who still holds the reins to it and can approve/reject an initiative to take over the project (and move it to github of course) if it is, in fact, abandoned? Is there anyone in the internals team who would be more qualified (and willing) than me to take over the project if it is, in fact, abandoned? (Re: qualification -- probably all of you. Re: willing -- I dunno, lol) Regards, Scott
Re: [PHP-DEV] Two small const correctness changes
On Thu, Dec 4, 2014 at 9:11 PM, Xinchen Hui wrote: > Hey: > > On Fri, Dec 5, 2014 at 8:08 AM, Levi Morrison wrote: >> These changes make ZVAL_COPY and ZVAL_COPY_VALUE work without warning >> for places where the zval that is copied is const: >> https://gist.github.com/morrisonlevi/69156fdf93e6bc82f9a0 >> >> In the default build there do not seem to be any places where this >> causes a warning, but I noticed it in an extension I'm writing. I do >> not yet have Zend Engine karma; hence posting to the list. > done. > > thanks Thank you for committing this. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Comparison chain
> On 5 Dec 2014, at 14:36, Дмитрий wrote: > > Hi! > > I followed by https://wiki.php.net/rfc/howto and I would like to propose a > concept "comparison chain" to implementing to future PHP versions. > It would be very usable if PHP can do that in python-style. > > Thank for your attension! Are you saying to allow (1 < x < 2) etc.? That would be nice, although it’s a backwards-compatibility break as currently (1 < x < 2) would do something different, as would, say, ($x == $y == $z). -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Comparison chain
Hi! I followed by https://wiki.php.net/rfc/howto and I would like to propose a concept "comparison chain" to implementing to future PHP versions. It would be very usable if PHP can do that in python-style. Thank for your attension!
[PHP-DEV] Comparison chain
Hi! I followed by https://wiki.php.net/rfc/howto and I would like to propose a concept "comparison chain" to implementing to future PHP versions. It would be very usable if PHP can do that in python-style. Thank for your attension!
[PHP-DEV] Comparison chain
Hi! I followed by https://wiki.php.net/rfc/howto and I would like to propose a concept "comparison chain" to implementing to future PHP versions. It would be very usable if PHP can do that in python-style. Thank for your attension!
Re: [PHP-DEV] Re: Only variables can be passed by reference
Hi Yasuo,
On Thu, Dec 4, 2014 at 11:38 AM, Yasuo Ohgaki wrote:
> Hi all,
>
> Sorry for multiple posts. This would be the last one.
>
> On Thu, Dec 4, 2014 at 7:08 PM, Yasuo Ohgaki wrote:
>
> > On Thu, Dec 4, 2014 at 5:28 PM, Yasuo Ohgaki wrote:
> >
> >> I think we can get rid of this error now when literal is returned.
> >> The reason we have E_STRICT error is that legacy PHP didn't
> >> support this, I suppose.
> >>
> >> http://3v4l.org/8fISj
> >>
> >> Is it possible to allow literal as referenced parameter for PHP7?
> >> It's better to remove needless restrictions where it is possible.
> >> HHVM seems already support this.
> >>
> >> http://3v4l.org/t79rF
> >>
> >> Any comments?
> >>
> >
> > I made a little better sample code.
> >
> > http://3v4l.org/d51DQ
> >
> > I would like to hear opinions from engine experts.
>
>
> Yet another sample code. This cannot be executed on 3v4l.org for security
> reasons.
>
> $sock = fsockopen('www.php.net', '80');
> var_dump($sock);
>
> $socks = array($sock);
> var_dump(stream_select($socks, $socks, $socks, 1));
>
> //var_dump(stream_select(array($sock), array($sock), array($sock), 1));
> //Fatal error: Only variables can be passed by reference in
> /home/yohgaki/tmp/ttt.php on line 8
> ?>
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>
Here is a real use case where removing this error would be beneficial:
https://github.com/mongofill/mongofill/issues/23#issuecomment-36469658
--
Thank you and best regards,
Eugene Leonovich
Re: [PHP-DEV] Re: Only variables can be passed by reference
On 5 December 2014 01:07:03 GMT, Yasuo Ohgaki wrote:
>Hi all,
>
>On Thu, Dec 4, 2014 at 5:28 PM, Yasuo Ohgaki
>wrote:
>
>> I think we can get rid of this error now when literal is returned.
>> The reason we have E_STRICT error is that legacy PHP didn't
>> support this, I suppose.
>>
>> http://3v4l.org/8fISj
>>
>> Is it possible to allow literal as referenced parameter for PHP7?
>> It's better to remove needless restrictions where it is possible.
>> HHVM seems already support this.
>>
>> http://3v4l.org/t79rF
>>
>> Any comments?
>>
>
>It may be better to focus on return value from functions/methods.
>
>There are cases that return values are better to be treated as usual
>variables. For example,
>
>function f1(&$v) {}
>function f2() {$a = array(1,2,3); return $a; }
>
>f1(f2());
>?>
>
>http://3v4l.org/2prWX
>
>E_STRICT error here is too much. IMHO.
>I think this kind of code should be allowed without errors rather than
>forcing users to save return value to variable. e.g.
>
>$v = f2();
>f1($v);
The author of function f1() presumably designed it to apply some change to $v,
rather than executing only for its side effects and return value. If the caller
wants to ignore this design, they can, but they are not using the function as
it was designed. If they pass a function return straight into it, they have no
way of capturing the change to $v which the author intended them to see.
E_STRICT seems like the perfect output for that: "what you're doing will work,
but it's probably not the best idea, and there's an easy tweak you might want
to consider".
You might want some way of saying "no, I really meant to do that" (more
elegantly than the @ operator), but E_STRICT is full of hints like this that
border on coding style, so if you don't like that, just mask it out of
error_reporting.
That's my 2 pence, anyway.
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
