[PHP-DEV] Re: glob() bug 47358

[Stas Malyshev]

Hi!

> Sorry, I missed that one. I suspect it was the time where I
> misconfigured git and branches did not get merged. Feel free to merge
> it back/backport as I won't be able to do it before Monday.

OK, I have backported it (and following Anatol's patches for it).

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Status of PHP 5.4

[Stas Malyshev]

Hi!

> PHP 5.3 has reached the real end of life. Will the effect be that from
> now on PHP 5.4 will only get security fixes?

There's no dependency between the two in the release RFC, but it would
probably make sense to move 5.4 into "security only" phase once 5.6 is
GA, and set EOL date for 1 year since that moment, as we did with 5.3.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Let's make a 5.7 release

[Andrea Faulds]

On 15 Aug 2014, at 02:06, Levi Morrison  wrote:

>> As PHP 7 may break backwards-compatibility, 5.7 gives us a chance to add 
>> deprecation warnings and such to help people prepare for 7.
> 
> The updated multiple default blocks in a switch statement proposes
> exactly this. Even if PHP 5.7 doesn't have any features I think it
> would make the transition to PHP 7 easier.

Right. The specification is a general motivation for 5.7 for me, actually. By 
specifying PHP we spot a lot of things that need fixing, and 5.7 is a good time 
to fix them or note that we’re going to fix them. That means we don’t have 
these loose ends lying around as specified behaviour for two or three years. It 
could also be the first version of PHP which would have the official 
specification and implementation released at the same time, I hope. :)
--
Andrea Faulds
http://ajf.me/





--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Let's make a 5.7 release

[Levi Morrison]

> As PHP 7 may break backwards-compatibility, 5.7 gives us a chance to add 
> deprecation warnings and such to help people prepare for 7.

The updated multiple default blocks in a switch statement proposes
exactly this. Even if PHP 5.7 doesn't have any features I think it
would make the transition to PHP 7 easier.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Let's make a 5.7 release

[Andrea Faulds]

Good evening,

I’ve kept putting this off, but given the current “move phpng to master” vote, 
I really can’t delay this any longer.

It looks like PHP 7 is going to happen and phpng will be the base of that. 
While we could move straight to PHP 7 after the release of PHP 5.6, I think 
there is some merit in having one more 5.x release, namely 5.7, which would 
follow our usual release process and come out next year.

PHP 7, as a major release, is likely to take much longer than a usual minor 
release. While some people might think one year is realistic, I highly doubt 
that, as I suspect phpng will not be the only new feature PHP 7 will contain. 
Major releases come with major changes, and I suspect some others will crop up, 
and these might delay the release. Because it will probably take two to three 
years, having a minor release in the meantime means userland developers won’t 
be starved of new features which don’t need to be in a major release and could 
be in a minor.

Another point is that PHP 7 is probably going to break backwards-compatibility 
more significantly than minors would. For starters, phpng will break extension 
compatibility, and new proposals are likely to break userland compatibility as 
well. By making 5.7 happen, developers will have more time to switch to PHP 7 
and can keep their existing codebases for longer.

As PHP 7 may break backwards-compatibility, 5.7 gives us a chance to add 
deprecation warnings and such to help people prepare for 7.

Finally, it is a fallback. If we do end up targeting 7 to come out next year, 
then if serious issues cause delays to 7, we will have a less ambitious and 
working new release to fall back on.

I should clarify that I don’t wish to delay phpng at all, I am very much in 
favour of it and excited about it, nor do I expect this to delay it. We can 
simply work on two releases at once: PHP 7, an ambitious BC-breaking release to 
come out later, and PHP 5.7, a safe, non-breaking release that will come out 
next year with the usual schedule.

Thoughts? 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] "PHP" namespace?

[Yasuo Ohgaki]

Hi all,

On Wed, Jul 30, 2014 at 9:35 PM, Rowan Collins 
wrote:

>
>- Consistent naming
>>   - Consistent parameter order
>>   - Graceful function/class/interface deprecation
>> (We know what we should do for these, right?)
>>
>
> I'm not sure if this was meant sincerely, or slightly tongue-in-cheek, but
> no, we definitely don't. It comes up on the list every few months (I've
> only been subscribed a short time, but this is at least the 4th time I've
> seen), and the general conclusion is there isn't an easy answer, and that
> adding more namespaces doesn't particularly help.
>

One of the discussion is mine, I suppose.
This is because cleaning up API cannot be done w/o breaking some except
simple aliasing.
Even if there are issues in API, there isn't a consensus for feasible
resolution yet.

Namespace is good resolution obviously. It accomplishes compatibility and
consistency at the same time
even when parameters or class/interface definitions are changed.


> Making small changes, such as extra function aliases, or identical
> versions of existing functions with switched parameter order, just adds to
> the overall confusion and list of special cases that users have to carry
> around when reading and writing code.
>

We make small changes in versions always. API changes are small changes
also.
The difference is BC. Since API change breaks APP, it wasn't changed for a
long time.
Use of alias was proposed several times, but it wasn't optimum and couldn't
reach to consensus.

With namespace, user may choose. We don't force users to *new* or *old*
way. There is no BC issue.
It's users' choice. If we care about confusion, we may change API only with
major release to minimize it.


That leaves the option of making larger changes, to design a clear new API,
> deliberately *minimising* the similarity to existing functions so it's
> clear when you're using what. The popular option for that is migrating
> chunks of functionality to OOP (as with DateTime), and to pseudo-OOP
> "scalar methods" (of which there are a couple of prototypes) - not to turn
> PHP into a pure OOP language, just to give us a chance to design a more
> consistent library of functions.


Unless we rewrite everything completely, it wouldn't be accomplished. This
has been said for years
(more than a decade AFAIK) and didn't happen. Therefore, new API is not
feasible by history.

Even when we rewrite everything, are we going to remove old API? It's BC,
so I guess not. Most
legacy/obscure API will remain as it is now and usable by default.

New API doesn't help some time. For example, SessionHandlerInterface has
some variations and
has issue for adding to it. Instead having many SessionHandlerXXXInterface,
simply selecting
proper namespace is simpler/cleaner. Having new Session2 class only for
simpler interface name
does not make sense.

Since we don't have new major release often, it would be good for users
cleaning up API with every
new major versions. Otherwise, legacy/obscure APIs will remain 10 years or
even 20 years later for sure.
(In fact, we have legacy APIs almost 20 years that are used commonly)

Use of namespace guarantees new PHP has consistent/modern API. This will
neutralize/negate all cons, IMO.

cons are
 - New php.ini (default namesapce setting)
 - Legacy API can be used and remains (this is pros also)
 - Confusing to current users by having versions of API. (confusing API is
confusing for both new and current users, too)

If there are more cons, please add them.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

Re: [PHP-DEV] Status of PHP 5.4

[Jan Ehrhardt]

Chris Wright in php.internals (Thu, 14 Aug 2014 22:55:09 +0100):
>The release of 5.6 should push 5.4 into security-only state, rather
>than the 5.3 EOL. I realise in this case it should happen at almost
>the same time (I think the plan is that 5.6.0RC3 is the last RC?) ...

There will be a 5.6.0RC4, so it will take at least three weeks.

Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] Fixes for bugs #65463, #66036

[Rasmus Lerdorf]

On 08/14/2014 01:43 PM, Keyur Govande wrote:
> Hello,
> 
> I've opened https://github.com/php/php-src/pull/770 for patches for bugs
> #65463, #66036. More details in the PR.
> 
> The bug is reproducible on PHP 5.4, 5.5 and 5.6 with and without
> --enable-zend-signals.
> 
> Please review, I'm hesitant to merge such a core change without more eyes.

The patch is simple enough and it has been running in production at Etsy
for quite a while now. But we have had shutdown order issues since
forever and I have lost track of all the various nuances of this
problem. As far as I can tell this doesn't cause any additional problems
and fixes an obvious and common segfault.

-Rasmus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Status of PHP 5.4

[Chris Wright]

On 14 August 2014 22:41, Andrea Faulds  wrote:
>
> On 14 Aug 2014, at 22:34, Jan Ehrhardt  wrote:
>
>> PHP 5.3 has reached the real end of life. Will the effect be that from
>> now on PHP 5.4 will only get security fixes?
>
> I’m curious about this too. The release process RFC says only bug fixes after 
> 2 years, and it is well beyond that now (5.4 came out March 2012).
>
> Look at the wikipedia page: https://en.wikipedia.org/wiki/PHP#Release_history
>
> That 5.4 bit should be yellow. 5.6 ought to be green, too, but alas this 
> release, like every, has been delayed.

For me this is a better way to explain why 5.4 is not (currently)
security only. We maintain the current and the previous, we should not
arbitrarily change the status of the previous before there is a new
current.

The release of 5.6 should push 5.4 into security-only state, rather
than the 5.3 EOL. I realise in this case it should happen at almost
the same time (I think the plan is that 5.6.0RC3 is the last RC?) but
let's imagine that 5.7 is delayed by 5 years for some reason - it's
reasonable to expect that 5.4 would be dropped a long time before 5.7
is released in this scenario, since "security only" mode is (as I see
it) only to give stragglers the chance to upgrade, we don't want to
maintain 3 branches for the sake of it.

The release process helps to ensure that upgrading should now be
considerably less painful that it previously was, and saying goodbye
to 5.3 means that all currently maintained branches have been
(largely) subject to this process. This makes "security only" for the
sake of stragglers less relevant, meaning that we shouldn't need to
keep 5.4 alive for nearly as long as 5.3 has been. Because of this,
when 5.4 *is* EOL, that doesn't necessarily mean that 5.5 is suddenly
security only.

IMO, YMMV

Thanks, Chris

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Status of PHP 5.4

[Andrea Faulds]

On 14 Aug 2014, at 22:34, Jan Ehrhardt  wrote:

> PHP 5.3 has reached the real end of life. Will the effect be that from
> now on PHP 5.4 will only get security fixes?

I’m curious about this too. The release process RFC says only bug fixes after 2 
years, and it is well beyond that now (5.4 came out March 2012).

Look at the wikipedia page: https://en.wikipedia.org/wiki/PHP#Release_history

That 5.4 bit should be yellow. 5.6 ought to be green, too, but alas this 
release, like every, has been delayed.

--
Andrea Faulds
http://ajf.me/





--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Status of PHP 5.4

[Jan Ehrhardt]

PHP 5.3 has reached the real end of life. Will the effect be that from
now on PHP 5.4 will only get security fixes?

Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Moving multiple defaults in switches RFC back to Under Disucssion.

[James Ward]

Oops.. somehow I only sent the reply to Levi.. I blame my phone.  Regardless,

Thank you for adopting the RFC and setting the status to under
discussion from its previous status of "Bike shedding" as I am not
sure if per the process we could discuss the merits of the change -
only the color of the patch.

On Aug 14, 2014 12:17 PM, "Levi Morrison"  wrote:
> The patch has not yet been updated to reflect the changes.

I have created a basic patch found
https://github.com/imnotjames/php-src/compare/switch.default.multiple-deprecated
Which emits an E_DEPRECATED.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Improved logarithm of base 2|10 of standard math function

[Marc Bennewitz]

On 14.08.2014 17:29, Sara Golemon wrote:
> On Thu, Aug 14, 2014 at 2:44 AM, Marc Bennewitz  wrote:
>> forgotten the link:
>> https://github.com/php/php-src/pull/658
>>
>>
>> On 14.08.2014 11:43, Marc Bennewitz wrote:
>>>
>>> Hi internals,
>>>
>>> I have created a PR to improve the base 2 and base 10 of the standard
>>> math function "log" to reduce rounding errors.
>>>
>>> Internally on log(x, 2) the native C function log2(x) and on log(x, 10)
>>> the native C function log10(x) will be called.
>>>
>>> The PR is open since april without any comments!
>>> Please please please someone there to merge this.
>>>
>>> PS:
>>> Because of after this PR the following will be the same in PHP log10(x)
>>> === log10(x) the function log10 is needless and could be
>>> deprecated/removed. I will create an RFC if this PR was merged.
>>>
>>
> This seems entirely reasonable and would be covered by existing unit
> tests.   No user-impacting effect (beyond being more precise/correct
> output).  I'll push this after my Dr appointment today if nobody has
> beaten me to it.

Nice to see it's merged - thanks!

> 
> -Sara
> 

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] [PATCH] Fixes for bugs #65463, #66036

[Keyur Govande]

Hello,

I've opened https://github.com/php/php-src/pull/770 for patches for bugs
#65463, #66036. More details in the PR.

The bug is reproducible on PHP 5.4, 5.5 and 5.6 with and without
--enable-zend-signals.

Please review, I'm hesitant to merge such a core change without more eyes.

Thanks,
Keyur.

[PHP-DEV] Moving multiple defaults in switches RFC back to Under Disucssion.

[Levi Morrison]

Dear list,

With her permission, I have taken ownership of Sara's RFC about
multiple default statements in switches. In summary I have:

 - Moved RFC from Voting back to Under Discussion
 - Made the RFC targets PHP 7 for an E_COMPILE_ERROR, with an
E_DEPRECATED targeted at PHP 5.7.
 - Made other miscellaneous changes.

The patch has not yet been updated to reflect the changes.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Evaluation of constructor arguments if there's no constructor

[Julien Pauli]

On Thu, Aug 14, 2014 at 2:42 PM, Rowan Collins  wrote:
> Julien Pauli wrote (on 14/08/2014):
>>
>> It may be possible to interpret the argument, but I think it will need
>>
>> new OPCodes, like ZEND_NEW_WITH_CTOR and ZEND_NEW_WITHOUT_CTOR , and a
>> compiler patch to support those.
>> This may be thought for PHP7, and I think will benefit from the
>> ast-compiler RFC if its voted.
>
>
> Yeah, to clarify, I was definitely thinking in terms of PHP7, where lots is
> already being done for consistency and parser changes.
>
> It may be naive of me, but would it be possible to simply add an implicit
> constructor with an empty argument list and body to any class which doesn't
> have one?

This would disable the actual executor optimization.
We need to rethink this problem for PHP7's executor.

Julien.Pauli

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Improved logarithm of base 2|10 of standard math function

[Sara Golemon]

On Thu, Aug 14, 2014 at 2:44 AM, Marc Bennewitz  wrote:
> forgotten the link:
> https://github.com/php/php-src/pull/658
>
>
> On 14.08.2014 11:43, Marc Bennewitz wrote:
>>
>> Hi internals,
>>
>> I have created a PR to improve the base 2 and base 10 of the standard
>> math function "log" to reduce rounding errors.
>>
>> Internally on log(x, 2) the native C function log2(x) and on log(x, 10)
>> the native C function log10(x) will be called.
>>
>> The PR is open since april without any comments!
>> Please please please someone there to merge this.
>>
>> PS:
>> Because of after this PR the following will be the same in PHP log10(x)
>> === log10(x) the function log10 is needless and could be
>> deprecated/removed. I will create an RFC if this PR was merged.
>>
>
This seems entirely reasonable and would be covered by existing unit
tests.   No user-impacting effect (beyond being more precise/correct
output).  I'll push this after my Dr appointment today if nobody has
beaten me to it.

-Sara

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] PHP 5.3.29 is available, PHP 5.3 reaching end of life

[Johannes Schlüter]

The PHP development team announces the immediate availability of PHP
5.3.29. This release marks the end of life of the PHP 5.3 series. Future
releases of this series are not planned. All PHP 5.3 users are
encouraged to upgrade to the current stable version of PHP 5.5 or
previous stable version of PHP 5.4, which are supported till at least
2016 and 2015 respectively.

PHP 5.3.29 contains about 25 potentially security related fixes
backported from PHP 5.4 and 5.5.

For source downloads of PHP 5.3.29, please visit our downloads page on
http://www.php.net/downloads.php Windows binaries can be found on
windows.php.net/download/. The list of changes is recorded in the
ChangeLog at http://www.php.net/ChangeLog-5.php#5.3.29

For helping your migration to newer versions please refer to our
migration guides for updates from PHP 5.3 to 5.4 and from PHP 5.4 to
5.5. On http://php.net/migration54 and http://php.net/migration55
accordingly.


Johannes Schlüter
PHP 5.3 Release Master



signature.asc
Description: This is a digitally signed message part

Re: [PHP-DEV] Evaluation of constructor arguments if there's no constructor

[Rowan Collins]

Julien Pauli wrote (on 14/08/2014):

It may be possible to interpret the argument, but I think it will need
new OPCodes, like ZEND_NEW_WITH_CTOR and ZEND_NEW_WITHOUT_CTOR , and a
compiler patch to support those.
This may be thought for PHP7, and I think will benefit from the
ast-compiler RFC if its voted.


Yeah, to clarify, I was definitely thinking in terms of PHP7, where lots 
is already being done for consistency and parser changes.


It may be naive of me, but would it be possible to simply add an 
implicit constructor with an empty argument list and body to any class 
which doesn't have one?


Because that's kind of what seems logical from the user point of view:

class A { }
==
class A { public function __construct() {} }

The same could also be achieved by having an implicit ancestor of all 
objects, because an empty constructor (and destructor) could be defined 
there, then over-ridden by whatever the user declares.


--
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Evaluation of constructor arguments if there's no constructor

[Julien Pauli]

On Thu, Aug 14, 2014 at 12:19 PM, Rowan Collins  wrote:
> Julien Pauli wrote (on 14/08/2014):
>
>> On Thu, Aug 14, 2014 at 8:26 AM, Tjerk Meesters
>>  wrote:
>>>
>>> Hi internals,
>>>
>>> I was sifting through the bucket o’ bugs and found these two related
>>> issues:
>>> https://bugs.php.net/bug.php?id=67829
>>> https://bugs.php.net/bug.php?id=54162 (closed)
>>>
>>> They concern the behaviour of the engine when a class defines no
>>> constructor or if the class to be instantiated doesn’t exist, which can be
>>> seen here: http://3v4l.org/jOQY0
>>>
>>> This is obviously a design decision, but doesn’t seem to have a mention
>>> in the documentation nor the spec (I couldn’t find it under the ‘new’
>>> operator).
>>>
>>> I can add a paragraph in the documentation for it; the question is
>>> whether it should also be added to the spec, seeing how HHVM and PHP behave
>>> differently in this respect? It could be added as implementation dependent
>>> behaviour I suppose?
>>
>> This is a known behavior which is part of the VM.
>> It is designed at http://lxr.php.net/xref/PHP_5_5/Zend/zend_vm_def.h#3383
>>
>> I guess its an optimisation that prevents the compiler from compiling
>> a ZEND_DO_FCALL for constructors, which optimizes a bit the VM path
>> for object construction.
>> Dmitry should have more informations.
>>
>> I'm +1 for a documentation or spec mention.
>>
>>
>> Julien.Pauli
>>
>
> When it came up on StackOverflow chat, it was cheekily dubbed "Rasmus
> evaluation", because nobody could find any theory matching that particular
> optimisation: https://chat.stackoverflow.com/transcript/11/2013/9/28/14-17
>
> I'm still not entirely sure it's a good idea, and can't imagine how anyone
> would rely on it (if you have a look at that trasnscript, you'll find some
> fun attempts at finding an esoteric use). Is it really that big an
> optimisation that it's worth such surprising behaviour?

Well, in fact the INIT_FCALL and DO_FCALL are generated by the
compiler, but the executor optimizes by jumping over all the opline of
the constructor if this latter is not declared at compile time.
As a side effect, if the argument is to be IS_VAR or IS_CV , it won't
be interpreted, thus this behavior.

It may be possible to interpret the argument, but I think it will need
new OPCodes, like ZEND_NEW_WITH_CTOR and ZEND_NEW_WITHOUT_CTOR , and a
compiler patch to support those.
This may be thought for PHP7, and I think will benefit from the
ast-compiler RFC if its voted.

Dmitry or Nikita could bring more information about this as well.

Julien.Pauli

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Introduce Abstract Syntax Tree

[Christoph Becker]

Michael Wallner wrote:

> On 14 08 2014, at 11:33, Alain Williams  wrote:
> 
>> It is OK to define some things as undefined and have them break between 
>> releases -
>> even minor releases. I always teach it as undefined - as it is in most
>> programming languages.
>>
>> Likewise, if the next 2 characters on input are 'a' then 'b' what gets 
>> assigned
>> could either be 'ab' or 'ba':
>>
>>$TwoChars = fgetc($in) . fgetc($in);
>>
>> Some code is just broken.
> 
> Wat? No. This is totally different to two in/decrements on one line. This has 
> to be executed in order.

The current specification draft says[1]:

| Unless stated explicitly in this specification, the order in which
| the operands in an expression are evaluated relative to each other is
| unspecified.
| [...]
| Finally, in the full expression f() + g() * h(), the order in which
| the three functions are called, is unspecified).

[1]


-- 
Christoph M. Becker

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Introduce Abstract Syntax Tree

[Michael Wallner]

On 14 08 2014, at 11:33, Alain Williams  wrote:

> On Thu, Aug 14, 2014 at 10:25:11AM +0100, Chris Wright wrote:
> 
>>> My personal opinion is that things like $a[$i++] = $i++ have zero practical
>>> relevance (and also think that anyone using something like this deserves
>>> any breakage he gets). I'd rather save some lines of code than maintain any
>>> behavior guarantees for that. But some people have contrary opinions on
>>> this, so I'm bringing up the point for discussion.
>> 
>> +1. It's documented as undefined behaviour, doing it in the first
>> place is highly non-obvious to the reader with a clear ambiguity, it's
>> fine by me to break from the current behaviour.
> 
> +1
> 
> It is OK to define some things as undefined and have them break between 
> releases -
> even minor releases. I always teach it as undefined - as it is in most
> programming languages.
> 
> Likewise, if the next 2 characters on input are 'a' then 'b' what gets 
> assigned
> could either be 'ab' or 'ba':
> 
>$TwoChars = fgetc($in) . fgetc($in);
> 
> Some code is just broken.

Wat? No. This is totally different to two in/decrements on one line. This has 
to be executed in order.

Cheers,
Mike


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Evaluation of constructor arguments if there's no constructor

[Rowan Collins]

Julien Pauli wrote (on 14/08/2014):

On Thu, Aug 14, 2014 at 8:26 AM, Tjerk Meesters
 wrote:

Hi internals,

I was sifting through the bucket o’ bugs and found these two related issues:
https://bugs.php.net/bug.php?id=67829
https://bugs.php.net/bug.php?id=54162 (closed)

They concern the behaviour of the engine when a class defines no constructor or 
if the class to be instantiated doesn’t exist, which can be seen here: 
http://3v4l.org/jOQY0

This is obviously a design decision, but doesn’t seem to have a mention in the 
documentation nor the spec (I couldn’t find it under the ‘new’ operator).

I can add a paragraph in the documentation for it; the question is whether it 
should also be added to the spec, seeing how HHVM and PHP behave differently in 
this respect? It could be added as implementation dependent behaviour I suppose?

This is a known behavior which is part of the VM.
It is designed at http://lxr.php.net/xref/PHP_5_5/Zend/zend_vm_def.h#3383

I guess its an optimisation that prevents the compiler from compiling
a ZEND_DO_FCALL for constructors, which optimizes a bit the VM path
for object construction.
Dmitry should have more informations.

I'm +1 for a documentation or spec mention.


Julien.Pauli



When it came up on StackOverflow chat, it was cheekily dubbed "Rasmus 
evaluation", because nobody could find any theory matching that 
particular optimisation: 
https://chat.stackoverflow.com/transcript/11/2013/9/28/14-17


I'm still not entirely sure it's a good idea, and can't imagine how 
anyone would rely on it (if you have a look at that trasnscript, you'll 
find some fun attempts at finding an esoteric use). Is it really that 
big an optimisation that it's worth such surprising behaviour?


--
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Improved logarithm of base 2|10 of standard math function

[Marc Bennewitz]

forgotten the link:
https://github.com/php/php-src/pull/658

On 14.08.2014 11:43, Marc Bennewitz wrote:

Hi internals,

I have created a PR to improve the base 2 and base 10 of the standard
math function "log" to reduce rounding errors.

Internally on log(x, 2) the native C function log2(x) and on log(x, 10)
the native C function log10(x) will be called.

The PR is open since april without any comments!
Please please please someone there to merge this.

PS:
Because of after this PR the following will be the same in PHP log10(x)
=== log10(x) the function log10 is needless and could be
deprecated/removed. I will create an RFC if this PR was merged.

Marc



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Improved logarithm of base 2|10 of standard math function

[Marc Bennewitz]

Hi internals,

I have created a PR to improve the base 2 and base 10 of the standard 
math function "log" to reduce rounding errors.


Internally on log(x, 2) the native C function log2(x) and on log(x, 10) 
the native C function log10(x) will be called.


The PR is open since april without any comments!
Please please please someone there to merge this.

PS:
Because of after this PR the following will be the same in PHP log10(x) 
=== log10(x) the function log10 is needless and could be 
deprecated/removed. I will create an RFC if this PR was merged.


Marc

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Introduce Abstract Syntax Tree

[Alain Williams]

On Thu, Aug 14, 2014 at 10:25:11AM +0100, Chris Wright wrote:

> > My personal opinion is that things like $a[$i++] = $i++ have zero practical
> > relevance (and also think that anyone using something like this deserves
> > any breakage he gets). I'd rather save some lines of code than maintain any
> > behavior guarantees for that. But some people have contrary opinions on
> > this, so I'm bringing up the point for discussion.
> 
> +1. It's documented as undefined behaviour, doing it in the first
> place is highly non-obvious to the reader with a clear ambiguity, it's
> fine by me to break from the current behaviour.

+1

It is OK to define some things as undefined and have them break between 
releases -
even minor releases. I always teach it as undefined - as it is in most
programming languages.

Likewise, if the next 2 characters on input are 'a' then 'b' what gets assigned
could either be 'ab' or 'ba':

$TwoChars = fgetc($in) . fgetc($in);

Some code is just broken.

-- 
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT 
Lecturer.
+44 (0) 787 668 0256  http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: 
http://www.phcomp.co.uk/contact.php
#include 

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Introduce Abstract Syntax Tree

[Chris Wright]

On 13 August 2014 20:05, Nikita Popov  wrote:
> On Wed, Aug 13, 2014 at 7:18 PM, guilhermebla...@gmail.com <
> guilhermebla...@gmail.com> wrote:
>
>> When is this planned to go through voting process?
>>
>
> Before voting I'd like to have some opinions on the behavioral differences
> the proposal introduces. In particular I'd like to know whether we are okay
> with changing order of evaluation in some places. We document that
> evaluation order is undefined, we document that it can change without
> warning between versions and that it is inconsistent within one version.
> However in the current implementation evaluation is usually left-to-right.
> The AST implementation introduces some places where evaluation is
> explicitly right-to-left, and not just incidentally.
>
> So basically the question is whether we are committed to things like
> $a[$i++] = $i++ or $a[$i++][$i++] = $j being undefined behavior, in which
> case order doesn't matter. If not, I can preserve left-to-right behavior
> here (CVs notwithstanding of course), but it would come at the cost of a
> good bit of additional complexity in the implementation (I suspect that I'd
> have to reintroduce parts of the bp stack to properly shuffle the oplines
> around).
>
> My personal opinion is that things like $a[$i++] = $i++ have zero practical
> relevance (and also think that anyone using something like this deserves
> any breakage he gets). I'd rather save some lines of code than maintain any
> behavior guarantees for that. But some people have contrary opinions on
> this, so I'm bringing up the point for discussion.

+1. It's documented as undefined behaviour, doing it in the first
place is highly non-obvious to the reader with a clear ambiguity, it's
fine by me to break from the current behaviour.

PHP is not and should not be designed around people who spend their
days playing code golf and/or optimising away one opcode at a time.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Evaluation of constructor arguments if there's no constructor

[Julien Pauli]

On Thu, Aug 14, 2014 at 8:26 AM, Tjerk Meesters
 wrote:
> Hi internals,
>
> I was sifting through the bucket o’ bugs and found these two related issues:
> https://bugs.php.net/bug.php?id=67829
> https://bugs.php.net/bug.php?id=54162 (closed)
>
> They concern the behaviour of the engine when a class defines no constructor 
> or if the class to be instantiated doesn’t exist, which can be seen here: 
> http://3v4l.org/jOQY0
>
> This is obviously a design decision, but doesn’t seem to have a mention in 
> the documentation nor the spec (I couldn’t find it under the ‘new’ operator).
>
> I can add a paragraph in the documentation for it; the question is whether it 
> should also be added to the spec, seeing how HHVM and PHP behave differently 
> in this respect? It could be added as implementation dependent behaviour I 
> suppose?

This is a known behavior which is part of the VM.
It is designed at http://lxr.php.net/xref/PHP_5_5/Zend/zend_vm_def.h#3383

I guess its an optimisation that prevents the compiler from compiling
a ZEND_DO_FCALL for constructors, which optimizes a bit the VM path
for object construction.
Dmitry should have more informations.

I'm +1 for a documentation or spec mention.


Julien.Pauli

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php