[PHP-DEV] Re: Is there documentation somewhere on public CMS/Framework/Libs thatare PHP7 compat?

[Tom Worster]

On 11/14/15 10:13 AM, Pascal Chevrel wrote:


Do you know of any public list of what CMS are working with PHP 7
without a problem? I am starting to test by myself what we use. My own
projects are of course PHP 7 compatible but we also have the usual tools
that open source project use for their day to day activities (blog,
wiki, forums...).


Yii 2 passes Travis on 7.

Tom

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

[PHP-DEV] Re: Is there documentation somewhere on public CMS/Framework/Libs thatare PHP7 compat?

[Andrea Faulds]

Hi Pascal,

Pascal Chevrel wrote:

Do you know of any public list of what CMS are working with PHP 7
without a problem? I am starting to test by myself what we use. My own
projects are of course PHP 7 compatible but we also have the usual tools
that open source project use for their day to day activities (blog,
wiki, forums...).


They don't have one yet, but this sounds like something that would be 
within the remit of the GoPHP7 project. They already have a list of 
compatible extensions, it would make sense for them to start a list of 
frameworks and software packages.


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] Windows (Visual Studio) compiler stuff

[Anatol Belski]

Hello Matt,

> -Original Message-
> From: Matt Wilmas [mailto:php_li...@realplain.com]
> Sent: Sunday, November 15, 2015 11:31 PM
> To: internals@lists.php.net; internals-...@lists.php.net
> Cc: Dmitry Stogov ; Anatol Belski
;
> Pierre Joye 
> Subject: [PHP-DEV] Windows (Visual Studio) compiler stuff
> 
> Hi Dmitry, Anatol, Pierre (etc.), and all,
> 
> I'm back now, I think, after a much longer (unintentional) break than I
expected.
> Be coming very soon with what I was doing in the summer (param parsing
stuff)
> -- *now* it works with MSVC too, barring any fragility, as I accidentally
> discovered last month...
> 
> I've been "discovering" a lot with the wacky Visual Studio compiler! :-)
This
> message is about the 2 I found today.
> 
> The first simple thing was probably just overlooked, but noticed it while
looking
> up __declspec.  zend_never_inline has always been empty (I guess) for
MSVC,
> but there's actually a __declspec(noinline) that can be used (and works as
> expected).  A simple and obvious change to bring it in line with the other
> compilers?
> 
According to the docs __declspec(noinline) is specific to C++. Also with VS
it's always much more tedious to inline something than the opposite. These
are the main two reasons it's disregarded ATM. We can add it for compliance
with C++, but it'll in best case have no effect in the PHP core. Should be
tested before, though.

> 
> The second "issue" is with the zend_always_inline functions, I noticed
this
> summer.  Did anyone else know that MSVC leaves a *copy* of those functions
in
> the output files (DLLs)?  What's the point of that?  When they've been
inlined,
> and not referenced otherwise, there should be no reason to emit code for a
> standalone function!
> 
> I remembered after seeing that behavior that a bit of my own
__forceinline'd
> code did NOT have extra function code, but forgot to investigate until
today.
> What's different about my function definition?  No "static"
> specifier!  So that's the key. :-)
> 
> But... non-static would create duplicate symbols, I thought.  But no, it
works!
> With just __forceinline, there's no errors. :^)
> 
> Can something be done about this?  It would cut the binary size down a
bit.
> A zend_static macro to be used with zend_always_inline...?
> 
I'd ask you for some concrete case for this, as I'm not sure to understand
exactly what you mean. The only case where an extra code would be generated
is with "__declspec(export) inline", but that's not the case anywhere within
PHP. 

Regards

Anatol



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

[PHP-DEV] building binaries with static objects

[Andone, Bogdan]

Hi guys,

Does anybody know why PHP sources are compiled as shared objects only on linux, 
meaning that libtool is adding -fPIC -DPIC flags during compilation?
Shared objects are mandatory for building libphp7 library and module 
extensions, but why are they used for building binaries like php-fpm, php-cgi 
or php?

I just observed that binaries built with static objects are ~1% quicker at 
runtime for real live workloads like WordPress. Despite the fact that binary 
size is higher than the current version, there is a visible gain in terms of 
reduction of instructions retired per request and iTLB loads and misses.

I am wondering if it is possible to have static compilation enabled by default 
in the Makefile. I managed to do it by brute force as I am not an expert in 
libtool and auto tools (I tried to play with -enable-static flag but with no 
luck...). Not sure if current behavior is by intent or just a miss; or what 
constraints have to be considered for portability reasons for other non linux 
platforms.

Kind Regards,
Bogdan Andone

Re: [PHP-DEV] Windows (Visual Studio) compiler stuff

[Matt Wilmas]

Hi Anatol,

- Original Message -
From: "Anatol Belski"
Sent: Monday, November 16, 2015


Hello Matt,


-Original Message-
From: Matt Wilmas [mailto:php_li...@realplain.com]
Sent: Sunday, November 15, 2015 11:31 PM
To: internals@lists.php.net; internals-...@lists.php.net
Cc: Dmitry Stogov ; Anatol Belski

;

Pierre Joye 
Subject: [PHP-DEV] Windows (Visual Studio) compiler stuff

Hi Dmitry, Anatol, Pierre (etc.), and all,

I'm back now, I think, after a much longer (unintentional) break than I

expected.

Be coming very soon with what I was doing in the summer (param parsing

stuff)

-- *now* it works with MSVC too, barring any fragility, as I accidentally
discovered last month...

I've been "discovering" a lot with the wacky Visual Studio compiler! :-)

This

message is about the 2 I found today.

The first simple thing was probably just overlooked, but noticed it while

looking

up __declspec.  zend_never_inline has always been empty (I guess) for

MSVC,
but there's actually a __declspec(noinline) that can be used (and works 
as
expected).  A simple and obvious change to bring it in line with the 
other

compilers?

According to the docs __declspec(noinline) is specific to C++. Also with 
VS

it's always much more tedious to inline something than the opposite. These
are the main two reasons it's disregarded ATM. We can add it for 
compliance

with C++, but it'll in best case have no effect in the PHP core. Should be
tested before, though.


Yeah, I know what the docs imply ("member function"), which is why I tested 
it.  I guess you missed my "works as expected" part. :-P


A test function that just returns a number was automatically inlined (plain 
C).  Using __declspec(noinline) it was call'ed instead.


Not sure if any of the "zend_never_inline" PHP stuff is getting inlined when 
it's desired not to be -- I'll compile PHP in a bit and see what it looks 
like with "noinline."



The second "issue" is with the zend_always_inline functions, I noticed

this
summer.  Did anyone else know that MSVC leaves a *copy* of those 
functions

in

the output files (DLLs)?  What's the point of that?  When they've been

inlined,
and not referenced otherwise, there should be no reason to emit code for 
a

standalone function!

I remembered after seeing that behavior that a bit of my own

__forceinline'd

code did NOT have extra function code, but forgot to investigate until

today.

What's different about my function definition?  No "static"
specifier!  So that's the key. :-)

But... non-static would create duplicate symbols, I thought.  But no, it

works!

With just __forceinline, there's no errors. :^)

Can something be done about this?  It would cut the binary size down a

bit.

A zend_static macro to be used with zend_always_inline...?


I'd ask you for some concrete case for this, as I'm not sure to understand
exactly what you mean. The only case where an extra code would be 
generated
is with "__declspec(export) inline", but that's not the case anywhere 
within

PHP.


My concrete case is checking tons of generated code! ;-)

It's simple: useless standalone functions are created for every "static 
__forceinline" definition...  Not having static makes it act like GCC/Clang.


Again, I'll try to compile PHP with those static's removed and report the 
effect later.



Regards

Anatol


- Matt 



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

[PHP-DEV] VCS Account Request: rkgudboy

[Rohit Kashyap]

Developing the PHP runtime
Maintaining an official, bundled PHP extension
Maintaining the documentation
Maintaining php.net


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

[PHP-DEV] Benchmark Results for PHP Master 2015-11-16

[lp_benchmark_robot]

Results for project PHP master, build date 2015-11-16 05:25:57+02:00
commit: 1a1349b336633e5977c41d555035c7146e06e0c7
revision date:  2015-11-16 08:16:07+11:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping 
2, LLC 45 MB
mem:128 GB
os: CentOS 7.1
kernel: Linux 3.10.0-229.4.2.el7.x86_64

Baseline results were generated using release php-7.0.0beta3, with hash
1674bd9b151ff389fb8c9fc223bc6aafdd49ff2c from 2015-08-05 04:56:40+00:00

---
benchmark   relative   change since   change since  
current rev run
std_dev*   last run   baseline  
   with PGO
---
:-)   Wordpress 4.2.2 cgi -T1  0.14% -0.09%  2.63%  
  7.61%
:-)   Drupal 7.36 cgi -T1  1.01% -0.33%  1.48%  
  4.18%
:-)   MediaWiki 1.23.9 cgi -T5000  0.25% -0.39%  1.77%  
  3.90%
:-( bench.php cgi -T1  0.08% -1.92%  1.34%  
  6.76%
:-)   micro_bench.php cgi -T1  0.03%  1.23%  1.85%  
  4.42%
:-(mandelbrot.php cgi -T1  0.11% -6.79% -1.01%  
  7.41%
---
Note: Benchmark results for Wordpress, Drupal, MediaWiki are measured in
fetches/second while all others are measured in seconds.
More details on measurements methodology at: 
https://01.org/lp/documentation/php-environment-setup.
* Relative Standard Deviation (Standard Deviation/Average)

Our lab does a nightly source pull and build of the PHP project and measures
performance changes against the previous stable version and the previous nightly
measurement. This is provided as a service to the community so that quality
issues with current hardware can be identified quickly.

Intel technologies' features and benefits depend on system configuration and may
require enabled hardware, software or service activation. Performance varies
depending on system configuration.


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

Re: [PHP-DEV] Is there documentation somewhere on public CMS/Framework/Libs that are PHP7 compat?

[Larry Garfield]

On 11/16/15 4:21 AM, Aurélien Dudouit wrote:

Hello,

Someone at OVH started this kind of survey a few days ago, and tries to
keep an up-to-date list:
https://forum.ovh.com/showthread.php/106907-Testez-PHP7-en-avant-premi%C3%A8re?s=f3af21aec8d6f6c59d3af8f037abec15 



Beware, french writing; I'm pushing for a translation.

Quick summary:

Compatible:
Wordpress >=4.3
Symfony 2.3, 2.6, 2.7, 3.0
Zend framework >=2.4
Laravel 5

Not yet compatible, future supported version:
Prestashop 1.6.1.2
Joomla 3.5
Drupal 8.0


Drupal 8 is compatible with PHP 7 as of the latest RC, we believe. Most 
of the issues Drupal ran into in the last few months were actually 
engine bugs that were reported and fixed.  At this time our test suite 
is fully passing on PHP 7, so once both have a .0.0 release we expect it 
to be fully supported.


--
--Larry Garfield


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

Re: [PHP-DEV] Immutable modifier

[Larry Garfield]

On 11/16/15 3:15 AM, Chris Riley wrote:

Hi,

There has been a lot of interest recently (eg psr-7) in immutable data. I'm
considering putting an RFC together to add language support for immutables:

immutable class Foo {
public $bar;
public function __construct($bar) {
$this->bar = $bar;
}
}

Immutable on a class declaration makes all (maybe only public?) properties
of the class immutable after construct; assigning to a property would
result in a Fatal error.

class Foo {
public $bar;
immutable public $baz;
}

Immutable on a property makes the property immutable once it takes on a
none null value. Attempts to modify the property after this results in a
fatal error.

Any thoughts?
~C


As a firm believer in the value of immutable data structures, I don't 
believe such a simple approach would be useful and would likely be 
counter-productive.


The trick is there are 2 cases for immutability: An immutable service 
object, and an immutable data object.


A service object should be immutable once it's setup.  However, that 
setup *may*, in some cases, involve setter injection.  That's inferior 
or constructor injection but that is not always feasible. In practice, 
I'm not sure we need new syntax here at all.


For data objects, this is where it gets interesting.  Data objects *do* 
need to be modifiable for a given context... for that context. Immutable 
data objects are, largely, useless and in my experience harmful unless 
they have a ->giveNewVersionWithThisOneChange() method.  In PSR-7, 
that's the with*() methods.  DateTimeImmutable has the same methods as 
DateTime, but they return new instances rather than modifying the 
invoked object (despite their confusing names, which are like that for 
historical reasons).


My ideal would be to revive the property RFC and leverage per-property 
access control separately for read and write to create 
externally-immutable objects.  That would allow for with*() methods to 
be implemented as appropriate for a given object.


The problem with a simple keyword approach is that "modifier" methods 
often should not, and in the case of PSR-7 cannot, correspond to simple 
get/set mapping to an object property.  (See withAddedHeader(), 
withoutHeader(), etc.)  Some level of flexibility needs to be given to 
the implementer to create an effectively-immutable object that is more 
than just a bare struct that's hard to work with.  If there were some 
way to flag for the compiler that "This object is supposed to be 
effectively-immutable, please check and make sure I didn't screw that 
up", that would be lovely but sounds hard. :-)


--
--Larry Garfield


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

Re: [PHP-DEV] Support for writing and executing compiled opcode Stephen Coakley <m...@stephencoakley.com>

[Jefferson Gonzalez]

On 11/14/2015 08:03 PM, Rasmus Lerdorf wrote:

Beyond that I can't picture what possible use this could be.


I also think that the ability to have a .phpc and .php side by side 
would be nice, but not for hiding the source code. It would be useful 
especially for php-cgi and secondary for php-cli. In php-cgi case theres 
people who still host multiple sites on a single server and use the 
php-cgi method because it doesn't requires to have an always running 
instance like with php-fpm.


Lets say you are hosting 100 sites on a single server, imho it would be 
less resourceful to run php-cgi processes on demand than having more 
than 100 fpm processes idling for requests. So in this scenario, having 
the flexibility to load byte code for php-cgi process would be a nice 
performance boost.



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

Re: [PHP-DEV] Support for writing and executing compiled opcode Stephen Coakley <m...@stephencoakley.com>

[Rasmus Lerdorf]

On 11/16/2015 03:13 PM, Jefferson Gonzalez wrote:
> On 11/14/2015 08:03 PM, Rasmus Lerdorf wrote:
>> Beyond that I can't picture what possible use this could be.
> 
> I also think that the ability to have a .phpc and .php side by side
> would be nice, but not for hiding the source code. It would be useful
> especially for php-cgi and secondary for php-cli. In php-cgi case theres
> people who still host multiple sites on a single server and use the
> php-cgi method because it doesn't requires to have an always running
> instance like with php-fpm.
> 
> Lets say you are hosting 100 sites on a single server, imho it would be
> less resourceful to run php-cgi processes on demand than having more
> than 100 fpm processes idling for requests. So in this scenario, having
> the flexibility to load byte code for php-cgi process would be a nice
> performance boost.

But that is exactly what the file-based opcache does by itself. The only
speedup you achieve by trying to distribute the .bin files would be a
minor boost the first time a cli script is executed. All subsequent runs
of the script would hit the cache. The added complexity and potential
version conflicts of trying to distribute the .bin files doesn't seem
like it would be worth the trouble for such a minor one-time performance
benefit.

-Rasmus




signature.asc
Description: OpenPGP digital signature

[PHP-DEV] RE: [INTERNALS-WIN] Re: [PHP-DEV] Windows (Visual Studio) compiler stuff

[Anatol Belski]

Hi Matt,

> -Original Message-
> From: Matt Wilmas [mailto:php_li...@realplain.com]
> Sent: Monday, November 16, 2015 2:59 PM
> To: Anatol Belski ; internals@lists.php.net;
internals-
> w...@lists.php.net
> Cc: 'Dmitry Stogov' ; 'Pierre Joye'

> Subject: [INTERNALS-WIN] Re: [PHP-DEV] Windows (Visual Studio) compiler
> stuff
> 
> > According to the docs __declspec(noinline) is specific to C++. Also
> > with VS it's always much more tedious to inline something than the
> > opposite. These are the main two reasons it's disregarded ATM. We can
> > add it for compliance with C++, but it'll in best case have no effect
> > in the PHP core. Should be tested before, though.
> 
> Yeah, I know what the docs imply ("member function"), which is why I
tested it.
> I guess you missed my "works as expected" part. :-P
> 
> A test function that just returns a number was automatically inlined
(plain C).
> Using __declspec(noinline) it was call'ed instead.
> 
> Not sure if any of the "zend_never_inline" PHP stuff is getting inlined
when it's
> desired not to be -- I'll compile PHP in a bit and see what it looks like
with
> "noinline."
> 
Yeah, I knew it could work, just that it's undocumented so preferred not
even to start with it because I haven't expect much gain from it. The
functions I've seen with zend_never_inline are rather big and wouldn't get
inlined even when forced.

> > I'd ask you for some concrete case for this, as I'm not sure to
> > understand exactly what you mean. The only case where an extra code
> > would be generated is with "__declspec(export) inline", but that's not
> > the case anywhere within PHP.
> 
> My concrete case is checking tons of generated code! ;-)
> 
> It's simple: useless standalone functions are created for every "static
> __forceinline" definition...  Not having static makes it act like
GCC/Clang.
>
I guess I've understood what you're talking about - abut unreferenced
COMDATs (or maybe also duplicated COMDATs). There is a variety of situations
for that, not possibly only inlining. Fixing it is done in PHP when building
with --enable-debug-pack, that is on in release builds. In your experiments,
if you add /Zi CFLAG (or explicitly /Gy) and /OPT:REF,ICF LDFLAG - that will
solve it for yur other project. You can read more about COMDAT on MSDN.

Hm, probably these options could be revisited, as since 2013 there's also
/Gw and /Zc:inline switches which is not implied by /Zi. But have to do more
checks, for now the release build options are good enough.
 
> Again, I'll try to compile PHP with those static's removed and report the
effect
> later.
> 
Yes, thanks for your effort. I actually didn't check what gcc does for such
cases, so curious. But "static" in "static inline" forces every translation
unit to have even the same function to have different address, thus
eliminating the "one definition" rule for inline. We anyway need "static
inline" best compatibility, the compilers handle the rest :)

Regards

Anatol 



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

Re: [PHP-DEV] Support for writing and executing compiled opcodeStephen Coakley <m...@stephencoakley.com>

[Rasmus Lerdorf]

On 11/16/2015 04:11 PM, Jefferson Gonzalez wrote:
> On 11/16/2015 04:22 PM, Rasmus Lerdorf wrote:
>> But that is exactly what the file-based opcache does by itself. The only
>> speedup you achieve by trying to distribute the .bin files would be a
>> minor boost the first time a cli script is executed. All subsequent runs
>> of the script would hit the cache. The added complexity and potential
>> version conflicts of trying to distribute the .bin files doesn't seem
>> like it would be worth the trouble for such a minor one-time performance
>> benefit.
>>
>> -Rasmus
>>
>>
> 
> But as far as I know thats only possible with php-cli and not with
> php-cgi, is it?

There is nothing cli-specific about this feature, so yes, it works fine
with php-cgi. You can set opcache.file_cache_only if you like to not
even try to create a shm cache and only use the file-based one for your
php-cgi setup.

-Rasmus



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Support for writing and executing compiled opcodeStephen Coakley <m...@stephencoakley.com>

[Jefferson Gonzalez]

On 11/16/2015 04:22 PM, Rasmus Lerdorf wrote:

But that is exactly what the file-based opcache does by itself. The only
speedup you achieve by trying to distribute the .bin files would be a
minor boost the first time a cli script is executed. All subsequent runs
of the script would hit the cache. The added complexity and potential
version conflicts of trying to distribute the .bin files doesn't seem
like it would be worth the trouble for such a minor one-time performance
benefit.

-Rasmus




But as far as I know thats only possible with php-cli and not with 
php-cgi, is it?


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

Re: [PHP-DEV] Immutable modifier

[Mathieu Rochette]

On 11/16/2015 11:11 PM, Larry Garfield wrote:

On 11/16/15 3:15 AM, Chris Riley wrote:

Hi,

There has been a lot of interest recently (eg psr-7) in immutable 
data. I'm
considering putting an RFC together to add language support for 
immutables:


immutable class Foo {
public $bar;
public function __construct($bar) {
$this->bar = $bar;
}
}

Immutable on a class declaration makes all (maybe only public?) 
properties

of the class immutable after construct; assigning to a property would
result in a Fatal error.

class Foo {
public $bar;
immutable public $baz;
}

Immutable on a property makes the property immutable once it takes on a
none null value. Attempts to modify the property after this results in a
fatal error.

Any thoughts?
~C


As a firm believer in the value of immutable data structures, I don't 
believe such a simple approach would be useful and would likely be 
counter-productive.

agreed


The trick is there are 2 cases for immutability: An immutable service 
object, and an immutable data object.


A service object should be immutable once it's setup.  However, that 
setup *may*, in some cases, involve setter injection.  That's inferior 
or constructor injection but that is not always feasible. In practice, 
I'm not sure we need new syntax here at all.
I'm curious here, why is construction not always enough ? do you have a 
use case in mind ?


For data objects, this is where it gets interesting.  Data objects 
*do* need to be modifiable for a given context... for that context. 
Immutable data objects are, largely, useless and in my experience 
harmful unless they have a ->giveNewVersionWithThisOneChange() 
method.  In PSR-7, that's the with*() methods.  DateTimeImmutable has 
the same methods as DateTime, but they return new instances rather 
than modifying the invoked object (despite their confusing names, 
which are like that for historical reasons).
How does that makes them mutable in a "given context" ? the with*() can 
always create a new object with everything in the constructor, am I 
missing something ?


My ideal would be to revive the property RFC and leverage per-property 
access control separately for read and write to create 
externally-immutable objects.  That would allow for with*() methods to 
be implemented as appropriate for a given object.
are you talking about this one ? 
https://wiki.php.net/rfc/readonly_properties


The problem with a simple keyword approach is that "modifier" methods 
often should not, and in the case of PSR-7 cannot, correspond to 
simple get/set mapping to an object property.  (See withAddedHeader(), 
withoutHeader(), etc.)  Some level of flexibility needs to be given to 
the implementer to create an effectively-immutable object that is more 
than just a bare struct that's hard to work with.  If there were some 
way to flag for the compiler that "This object is supposed to be 
effectively-immutable, please check and make sure I didn't screw that 
up", that would be lovely but sounds hard. :-)





--
Mathieu Rochette


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

Re: [PHP-DEV] Immutable modifier

[Sebastian Bergmann]

On 11/16/2015 04:15 AM, Chris Riley wrote:

Any thoughts?


 Would love to have it for implementing value objects.

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

Re: [PHP-DEV] Immutable modifier

[Levi Morrison]

On Mon, Nov 16, 2015 at 2:15 AM, Chris Riley  wrote:

> Hi,
>
> There has been a lot of interest recently (eg psr-7) in immutable data. I'm
> considering putting an RFC together to add language support for immutables:
>
> immutable class Foo {
> public $bar;
> public function __construct($bar) {
> $this->bar = $bar;
> }
> }
>
> Immutable on a class declaration makes all (maybe only public?) properties
> of the class immutable after construct; assigning to a property would
> result in a Fatal error.
>
> class Foo {
> public $bar;
> immutable public $baz;
> }
>
> Immutable on a property makes the property immutable once it takes on a
> none null value. Attempts to modify the property after this results in a
> fatal error.
>
> Any thoughts?
> ~C
>

In my opinion we should just generalize const for this, rather than add a
new keyword.

Re: [PHP-DEV] Support for writing and executing compiled opcode

[Sara Golemon]

On Mon, Nov 16, 2015 at 12:13 PM, Jefferson Gonzalez  wrote:
> On 11/14/2015 08:03 PM, Rasmus Lerdorf wrote:
>>
>> Beyond that I can't picture what possible use this could be.
>
>
> I also think that the ability to have a .phpc and .php side by side would be
> nice, but not for hiding the source code. It would be useful especially for
> php-cgi and secondary for php-cli. In php-cgi case theres people who still
> host multiple sites on a single server and use the php-cgi method because it
> doesn't requires to have an always running instance like with php-fpm.
>
Which OpCache's file-backend covers...

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

Re: [PHP-DEV] Immutable modifier

[Larry Garfield]

On 11/16/15 5:11 PM, Mathieu Rochette wrote:


On 11/16/2015 11:11 PM, Larry Garfield wrote:

On 11/16/15 3:15 AM, Chris Riley wrote:


Immutable on a property makes the property immutable once it takes on a
none null value. Attempts to modify the property after this results 
in a

fatal error.

Any thoughts?
~C


As a firm believer in the value of immutable data structures, I don't 
believe such a simple approach would be useful and would likely be 
counter-productive.

agreed


The trick is there are 2 cases for immutability: An immutable service 
object, and an immutable data object.


A service object should be immutable once it's setup.  However, that 
setup *may*, in some cases, involve setter injection. That's inferior 
or constructor injection but that is not always feasible. In 
practice, I'm not sure we need new syntax here at all.
I'm curious here, why is construction not always enough ? do you have 
a use case in mind ?


There are various cases, like a logger, a container-aware service (such 
as factories), or other cases where you may want a class to opt-in to a 
specific dependency by interface.  In that case your object creation 
process (DI Container or otherwise) can do something like this:


$object = create_object_via_constructor_injection(...);
if ($object instanceof Loggable) {
  $object->setLogger($this->getSystemLogger());
}

There are also cases in, eg, Drupal where forcing constructor injection 
for a class that is extending another results in unnecessary and 
annoying boilerplate.  (I'm thinking of our new Plugin system.)  As I 
said, it's suboptimal but use cases for setter injection (really 
interface injection) do exist, so a language-strict enforcement of 
constructor-or-nothing are not always applicable.


In any event, I don't think service objects really need this feature 
anyway as there's no data on the service to access; if it had any, it 
wouldn't be a service object. :-)


For data objects, this is where it gets interesting.  Data objects 
*do* need to be modifiable for a given context... for that context. 
Immutable data objects are, largely, useless and in my experience 
harmful unless they have a ->giveNewVersionWithThisOneChange() 
method.  In PSR-7, that's the with*() methods.  DateTimeImmutable has 
the same methods as DateTime, but they return new instances rather 
than modifying the invoked object (despite their confusing names, 
which are like that for historical reasons).
How does that makes them mutable in a "given context" ? the with*() 
can always create a new object with everything in the constructor, am 
I missing something ?


The "everything in the constructor" is the problem.  That results in, 
essentially, an obscenely long function call that just happens to be 
named __construct().  If I wanted something that obscure and hard to 
work with I'd just use anonymous arrays. :-)


Consider PSR-7's ServerRequest object.  It's immutable.  However, when 
passing it from one middleware to the next you want to be able to pass a 
"modified" version of it, containing extra properties that indicate the 
result of routing, for example.  Or you have a middleware that does 
cookie encryption, so it needs to "modify" the cookie header.


If that meant each middleware needed to do something like this:

function routing_middleware(ServerRequest $r, callable $next) {
  $attributes = $r->getAttributes();
  $attributes['controller'] = 'foo';

  $new = new ServerRequest($r->getMethod(), $r->getUri(), 
$r->getHeaders(), $r->getBody(), $r->getAttributes());


  return $next($new);
}

Well, you can see how gross that is, and it gets worse as soon as you 
need to modify more than one property. You essentially need to extract() 
the object back to primitives and build a new one, which is more 
cumbersome, more verbose, slower, and makes kittens cry.  At this point 
it's easier to just have a big anonymous array and pass that around; 
it's no less self-documenting and easier to work with.


(I had to work with such an object once when doing a Symfony REST 
project, because that's what the HATEOAS bundle did.  It was impossible 
to work with.)


Instead, with the with*() methods, PSR-7 lets you do this:

function routing_middleware(ServerRequest $r, callable $next) {
  $new = $r->withAttribute('controller', 'foo');

  return $next($new);
}

Or even inline that to a single line (if you really do have a hard coded 
controller, which is unlikely but other cases like cookie encryption might).


function cookie_middleware(ServerRequest $r, callable $next) {
  return $next($r->withHeader('Cookie', 
decode_cookie($r->getHeader('Cookie')));

}

Which looks nice and functional, too.

It's much easier to read, much easier to write, still communicates 
intent, and thanks to copy-on-write is no more expensive under usual usage.


Most of the objection to immutable PSR-7 objects, including my own, was 
based on the assumption that we'd be stuck with the former example, 
which is a major 

Re: [PHP-DEV] Immutable modifier

[Andrea Faulds]

Hi,

Chris Riley wrote:


There has been a lot of interest recently (eg psr-7) in immutable data. I'm
considering putting an RFC together to add language support for immutables:



I wonder if immutable classes are really the right way to go. Immutable 
reference types with manual copying are somewhat alien to PHP: instead, 
the language has used copy-on-write mutable value types for arrays and 
strings, and prior to PHP 5, objects.


Copy-on-write value types have all the benefits immutable types do. They 
can't be mutated at a distance unless you make a reference to them, 
trees made of them can be compared for equality with just ===, etc.


But they also have benefits that immutable types lack. They're easier to 
work with, because you can directly mutate them like everyone's used to 
doing: no messing around with withFooBar() and withoutFooBar(), you just 
set foobar or remove it directly. And PHP handles the duplication of 
objects for you implicitly, so there's far less code to write.


Unfortunately, PHP 5 got rid of PHP 4's value type objects and replaced 
them with reference type objects. But we could always introduce a way to 
get value type objects again. How about a `struct` keyword? It would be 
equivalent to `class`, but produce a value type rather than a reference 
type.


Any 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] Immutable modifier

[Andrea Faulds]

Hi Larry,

Larry Garfield wrote:

The "everything in the constructor" is the problem.  That results in,
essentially, an obscenely long function call that just happens to be
named __construct().  If I wanted something that obscure and hard to
work with I'd just use anonymous arrays. :-)


Huh?

"with" methods and __construct are not exclusive. In fact, you could 
have a private constructor and only have "with" methods. Only allowing 
assignment to properties in the constructor doesn't prevent having a 
nice API: have your methods call the constructor.


I don't see what you're getting at here.

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

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

Re: [PHP-DEV] Immutable modifier

[Anthony Ferrara]

Chris,

On Mon, Nov 16, 2015 at 4:15 AM, Chris Riley  wrote:
> Hi,
>
> There has been a lot of interest recently (eg psr-7) in immutable data. I'm
> considering putting an RFC together to add language support for immutables:
>
> immutable class Foo {
> public $bar;
> public function __construct($bar) {
> $this->bar = $bar;
> }
> }
>
> Immutable on a class declaration makes all (maybe only public?) properties
> of the class immutable after construct; assigning to a property would
> result in a Fatal error.
>
> class Foo {
> public $bar;
> immutable public $baz;
> }
>
> Immutable on a property makes the property immutable once it takes on a
> none null value. Attempts to modify the property after this results in a
> fatal error.

Beyond syntax/whatever, I would suggest finding a method to do it
internally. That's going to be the biggest problem in my experience
(finding some way of doing it efficiently)...

Anthony

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

Re: [PHP-DEV] Is there documentation somewhere on public CMS/Framework/Libs that are PHP7 compat?

[Aurélien Dudouit]

Hello,

Someone at OVH started this kind of survey a few days ago, and tries to
keep an up-to-date list:
https://forum.ovh.com/showthread.php/106907-Testez-PHP7-en-avant-premi%C3%A8re?s=f3af21aec8d6f6c59d3af8f037abec15

Beware, french writing; I'm pushing for a translation.

Quick summary:

Compatible:
Wordpress >=4.3
Symfony 2.3, 2.6, 2.7, 3.0
Zend framework >=2.4
Laravel 5

Not yet compatible, future supported version:
Prestashop 1.6.1.2
Joomla 3.5
Drupal 8.0


My two cents,

Aurélien


On 11/14/2015 04:13 PM, Pascal Chevrel wrote:

Hi guys,

I am very exceited about the imminent release of PHP 7 and that also
corresponds to when my non-profit will get a new server sponsored by a
local ISP, so we want to switch to 7 at this occasion, right in December ;)

Do you know of any public list of what CMS are working with PHP 7
without a problem? I am starting to test by myself what we use. My own
projects are of course PHP 7 compatible but we also have the usual tools
that open source project use for their day to day activities (blog,
wiki, forums...).

The nice news of the day for me is that the Dotclear blogging platform
works fine with PHP 7 and flies :) (tested on a shared OVH hosting which
allows activating PHP 7 via a config flag). Is there some wiki page
somewhere where I could document what I know works and others would do
the same so as to ease the migration of early adopters, especially those
of us that are open source hacktivists and don't have IT department to
check those things for us?

Cheers

Pascal




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

[PHP-DEV] Immutable modifier

[Chris Riley]

Hi,

There has been a lot of interest recently (eg psr-7) in immutable data. I'm
considering putting an RFC together to add language support for immutables:

immutable class Foo {
public $bar;
public function __construct($bar) {
$this->bar = $bar;
}
}

Immutable on a class declaration makes all (maybe only public?) properties
of the class immutable after construct; assigning to a property would
result in a Fatal error.

class Foo {
public $bar;
immutable public $baz;
}

Immutable on a property makes the property immutable once it takes on a
none null value. Attempts to modify the property after this results in a
fatal error.

Any thoughts?
~C

Re: [PHP-DEV] Immutable modifier

[Daniel Persson]

Any differance from the final keyword?

http://php.net/manual/en/language.oop5.final.php

On Mon, Nov 16, 2015 at 10:15 AM, Chris Riley  wrote:

> Hi,
>
> There has been a lot of interest recently (eg psr-7) in immutable data. I'm
> considering putting an RFC together to add language support for immutables:
>
> immutable class Foo {
> public $bar;
> public function __construct($bar) {
> $this->bar = $bar;
> }
> }
>
> Immutable on a class declaration makes all (maybe only public?) properties
> of the class immutable after construct; assigning to a property would
> result in a Fatal error.
>
> class Foo {
> public $bar;
> immutable public $baz;
> }
>
> Immutable on a property makes the property immutable once it takes on a
> none null value. Attempts to modify the property after this results in a
> fatal error.
>
> Any thoughts?
> ~C
>

Re: [PHP-DEV] Immutable modifier

[Chris Riley]

On 16 November 2015 at 09:24, Daniel Persson  wrote:

> Any differance from the final keyword?
>
> http://php.net/manual/en/language.oop5.final.php
>
> On Mon, Nov 16, 2015 at 10:15 AM, Chris Riley  wrote:
>
>> Hi,
>>
>> There has been a lot of interest recently (eg psr-7) in immutable data.
>> I'm
>> considering putting an RFC together to add language support for
>> immutables:
>>
>> immutable class Foo {
>> public $bar;
>> public function __construct($bar) {
>> $this->bar = $bar;
>> }
>> }
>>
>> Immutable on a class declaration makes all (maybe only public?) properties
>> of the class immutable after construct; assigning to a property would
>> result in a Fatal error.
>>
>> class Foo {
>> public $bar;
>> immutable public $baz;
>> }
>>
>> Immutable on a property makes the property immutable once it takes on a
>> none null value. Attempts to modify the property after this results in a
>> fatal error.
>>
>> Any thoughts?
>> ~C
>>
>
>
Yes, final prevents child classes from overriding a method or from
extending a class entirely, this is a compile time constraint. Immutable
prevents data modifications and as such is a run time constraint.

~C

Re: [PHP-DEV] Immutable modifier

[Lorenzo Fontana]

I really like the concept of immutability, but I think that it should be
applicable at  instance level rather than declaration.

I would also prefer another keyword than immutable.

Final does not make the properties immutable, it makes the class not
extensible.
On Nov 16, 2015 10:24, "Daniel Persson"  wrote:

> Any differance from the final keyword?
>
> http://php.net/manual/en/language.oop5.final.php
>
> On Mon, Nov 16, 2015 at 10:15 AM, Chris Riley  wrote:
>
> > Hi,
> >
> > There has been a lot of interest recently (eg psr-7) in immutable data.
> I'm
> > considering putting an RFC together to add language support for
> immutables:
> >
> > immutable class Foo {
> > public $bar;
> > public function __construct($bar) {
> > $this->bar = $bar;
> > }
> > }
> >
> > Immutable on a class declaration makes all (maybe only public?)
> properties
> > of the class immutable after construct; assigning to a property would
> > result in a Fatal error.
> >
> > class Foo {
> > public $bar;
> > immutable public $baz;
> > }
> >
> > Immutable on a property makes the property immutable once it takes on a
> > none null value. Attempts to modify the property after this results in a
> > fatal error.
> >
> > Any thoughts?
> > ~C
> >
>

[PHP-DEV] VCS Account Request: anaymalpani

[ABHIHEK MALPANI]

i m intreassted


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

Re: [PHP-DEV] Immutable modifier

[Chris Riley]

On 16 November 2015 at 09:33, Lorenzo Fontana 
wrote:

> I really like the concept of immutability, but I think that it should be
> applicable at  instance level rather than declaration.
>
> I would also prefer another keyword than immutable.
>
> Final does not make the properties immutable, it makes the class not
> extensible.
> On Nov 16, 2015 10:24, "Daniel Persson"  wrote:
>
>> Any differance from the final keyword?
>>
>> http://php.net/manual/en/language.oop5.final.php
>>
>> On Mon, Nov 16, 2015 at 10:15 AM, Chris Riley 
>> wrote:
>>
>> > Hi,
>> >
>> > There has been a lot of interest recently (eg psr-7) in immutable data.
>> I'm
>> > considering putting an RFC together to add language support for
>> immutables:
>> >
>> > immutable class Foo {
>> > public $bar;
>> > public function __construct($bar) {
>> > $this->bar = $bar;
>> > }
>> > }
>> >
>> > Immutable on a class declaration makes all (maybe only public?)
>> properties
>> > of the class immutable after construct; assigning to a property would
>> > result in a Fatal error.
>> >
>> > class Foo {
>> > public $bar;
>> > immutable public $baz;
>> > }
>> >
>> > Immutable on a property makes the property immutable once it takes on a
>> > none null value. Attempts to modify the property after this results in a
>> > fatal error.
>> >
>> > Any thoughts?
>> > ~C
>> >
>>
>
What instance level syntax would you propose?

$foo = new immutable bar();  ?

or

immutable $foo = new bar();

Gives less flexibility imo and less guarantees of correctness.

Consider the current user land implementation of immutable classes:

class Foo {
private $bar;
public function __construct($bar) {
$this->bar = $bar;
}

public function getBar() {
return $this->bar;
}
}

Is already done at declaration declaration based immutability is probably
more desirable.

What keyword would you suggest other than immutable?

~C

Re: [PHP-DEV] Immutable modifier

[Mathieu Rochette]

hi,

On 16/11/2015 10:33, Lorenzo Fontana wrote:

I really like the concept of immutability, but I think that it should be
applicable at  instance level rather than declaration.
I'm not sure about that, most PHP code assume mutable objects, I doubt 
much existing classes would be usable as immutable


I would also prefer another keyword than immutable.

Final does not make the properties immutable, it makes the class not
extensible.
On Nov 16, 2015 10:24, "Daniel Persson"  wrote:


Any differance from the final keyword?

http://php.net/manual/en/language.oop5.final.php

On Mon, Nov 16, 2015 at 10:15 AM, Chris Riley  wrote:


Hi,

There has been a lot of interest recently (eg psr-7) in immutable data.

I'm

considering putting an RFC together to add language support for

immutables:

immutable class Foo {
public $bar;
public function __construct($bar) {
$this->bar = $bar;
}
}

Immutable on a class declaration makes all (maybe only public?)

properties
I don't think it's enough to make only public properties immutable. this 
would lead to a lot of mutable "immutable" classes, eg:


immutable class my_class {
  private $my_prop;
  __construct($my_prop) {
$this->my_prop = $my_prop;
  }
  public function getMyProp() {
return $this->my_prop;
  }
  public function setMyProp($my_prop) {
return $this->my_prop = $my_prop;
  }
}

how is this class immutable ?
also, what about __isset/__set ? Would it be allowed to assign non 
immutable types to properties of an immutable class ?

of the class immutable after construct; assigning to a property would
result in a Fatal error.

class Foo {
public $bar;
immutable public $baz;
}

Immutable on a property makes the property immutable once it takes on a
none null value. Attempts to modify the property after this results in a
fatal error.

Any thoughts?
~C




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

Re: [PHP-DEV] Immutable modifier

[Lorenzo Fontana]

2015-11-16 10:40 GMT+01:00 Chris Riley :

>
>
> On 16 November 2015 at 09:33, Lorenzo Fontana 
> wrote:
>
>> I really like the concept of immutability, but I think that it should be
>> applicable at  instance level rather than declaration.
>>
>> I would also prefer another keyword than immutable.
>>
>> Final does not make the properties immutable, it makes the class not
>> extensible.
>> On Nov 16, 2015 10:24, "Daniel Persson"  wrote:
>>
>>> Any differance from the final keyword?
>>>
>>> http://php.net/manual/en/language.oop5.final.php
>>>
>>> On Mon, Nov 16, 2015 at 10:15 AM, Chris Riley 
>>> wrote:
>>>
>>> > Hi,
>>> >
>>> > There has been a lot of interest recently (eg psr-7) in immutable
>>> data. I'm
>>> > considering putting an RFC together to add language support for
>>> immutables:
>>> >
>>> > immutable class Foo {
>>> > public $bar;
>>> > public function __construct($bar) {
>>> > $this->bar = $bar;
>>> > }
>>> > }
>>> >
>>> > Immutable on a class declaration makes all (maybe only public?)
>>> properties
>>> > of the class immutable after construct; assigning to a property would
>>> > result in a Fatal error.
>>> >
>>> > class Foo {
>>> > public $bar;
>>> > immutable public $baz;
>>> > }
>>> >
>>> > Immutable on a property makes the property immutable once it takes on a
>>> > none null value. Attempts to modify the property after this results in
>>> a
>>> > fatal error.
>>> >
>>> > Any thoughts?
>>> > ~C
>>> >
>>>
>>
> What instance level syntax would you propose?
>
> $foo = new immutable bar();  ?
>
> or
>
> immutable $foo = new bar();
>
> Gives less flexibility imo and less guarantees of correctness.
>
> Consider the current user land implementation of immutable classes:
>
> class Foo {
> private $bar;
> public function __construct($bar) {
> $this->bar = $bar;
> }
>
> public function getBar() {
> return $this->bar;
> }
> }
>
> Is already done at declaration declaration based immutability is probably
> more desirable.
>
> What keyword would you suggest other than immutable?
>
> ~C
>



I would prefer


immutable $foo = new bar();

that can also be applied to:

immutable $bar = "string";
immutable $baz = 1;
immutable $arr = [1, 2, 3];

and not only to classes.

The "userland implementation of immutable classes" you are proposing is not
immutable at all.
First of all one could define another accessor method that can change the
state or can bind a closure to $this and change an internal property at
runtime.

Some possible keywords that "means" immutable to me are:

let $bar = "string";
val $bar = "string";

What do you think?

Re: [PHP-DEV] Immutable modifier

[Rowan Collins]

Mathieu Rochette wrote on 16/11/2015 10:00:
Would it be allowed to assign non immutable types to properties of an 
immutable class ?


I think this is the trickiest part of trying to enforce immutability: 
nesting. Consider the following:


// Basic properties
$my_immutable_object->foo = 42;
$my_immutable_object->foo++;

// Nested object - implicitly immutable? required to be explicitly 
immutable?

$my_immutable_object->bar->something = 42;
$my_immutable_object->bar->setSomething(42);

// Array access - no idea how this should work
$my_immutable_object->quux[0] = 42;
$my_immutable_object->quux[] = 'Hello';
$my_immutable_object->quux['World'][0]['X'] = 'A';


The other problem is that to be useful, certain functions usually need 
to be able to mutate the state of objects which are officially 
immutable. For instance, implementations of PSR-7 need a set of copy 
constructors for the withX methods. You could do this using the 
suggested rule that immutability applies only to non-null properties, 
and manually populate every property of an empty instance, but it's much 
more efficient to "clone $this" and then change the one property that 
needs to be different.


For this particular example, you could write quite a nice implementation 
by "freezing" the instance once it's initialised:


// example plucked from 
https://github.com/guzzle/psr7/blob/master/src/Request.php#L101

public function withMethod($method)
{
// The method starts by making a mutable clone of the immutable 
$this

$new = clone $this;
$new->method = strtoupper($method);

# SUGGESTED ADDITION: new keyword to set an object to be immutable
freeze $new;
// After this point, nothing should be able to mutate the new 
object, only clone it


return $new;
}


The freeze operation could perhaps be recursive, or perhaps it could 
work like "clone", with an "__freeze" method responsible for freezing 
nested objects as necessary. The ability to freeze an array would also 
be useful in that case...


I realise this is a lot more complex than the original suggestion, but I 
think something of this level of detail is needed to make it useful.


Regards,
--
Rowan Collins
[IMSoP]

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

RE: [PHP-DEV] Re: Benchmark Results for PHP Master 2015-11-12

[Andone, Bogdan]

> -Original Message-
> From: Matt Wilmas [mailto:php_li...@realplain.com]
> Sent: Friday, November 13, 2015 1:49 PM
> To: internals@lists.php.net; Andrea Faulds
> Subject: Re: [PHP-DEV] Re: Benchmark Results for PHP Master 2015-11-12
> 
> Hi,
> 
> - Original Message -
> From: "Andrea Faulds"
> Sent: Friday, November 13, 2015
> 
> > Hi,
> >
> > lp_benchmark_ro...@intel.com wrote:
> >>
> >> -
> --
> >>  benchmark   relative   change since   change
> >> since  current rev run
> >>  std_dev*   last run
> >> baseline with PGO
> >> -
> --
> >> :-(   Wordpress 4.2.2 cgi -T1
> >> 9% -3.67% -1.28%6.51%
> >> :-(   Drupal 7.36 cgi -T1
> >> 8% -2.03% -0.67%2.63%
> >> :-(   MediaWiki 1.23.9 cgi -T5000
> >> 1% -3.19% -0.97%3.84%
> >> :-( bench.php cgi -T1
> >> 08%-16.51%-12.70%9.68%
> >> :-(   micro_bench.php cgi -T1  0.03% -1.50%
> >> 0.10%5.41%
> >> :-(mandelbrot.php cgi -T1
> >> 31%-25.68%-18.78%   -0.74%
> >> -
> --
> >
> >
> > Huh? Sad faces across the board, as bad as -25% for one test?
> >
> > Did we have to change something and it inadvertently affected
> performance?
> > This looks pretty bad.
> 
> Yup, I noticed right away yesterday and wondered the same, but decided
> to
> hold off on commenting until the next report(s) come(s). :-)
> 
> I figured it might have happened "between some changes that weren't
> optimal," but after the commits were finalized, etc. it would be sorted
> out
> again.  But this does seem pretty extreme, and I don't recall seeing
> radical
> changes since the last one... *shrug*
Indeed, it seemed that the sources "sampling" occurred on an unstable commit. 
We didn't escalate explicitly the issue as we saw it solved during the next day 
with the performance back on track.
Not sure if this was the cause, but having a short look at the commits applied 
just before and after the performance drop we observed several iterations and 
reverts on #70895 and #70898.

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

Kind Regards,
Bogdan


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

[PHP-DEV] taint as a first-class feature for php 7.1

[Christopher Owen]

Hello again php-internals.

I was the original poster of the (most recent) thread on making taint a 
first-class feature for php.

Shortly after the start of the original thread, Laruence ported the existing 
php-taint extension to php7 (thank you very much sir!).

For those of you who might like to try, I have been able to successfully test 
against php 7.0-rc7 using the following steps:

~~ build php-taint for php7

   git clone -b php7 https://github.com/laruence/taint.git php-taint
   cd php-taint
   /phpize
   ./configure --with-php-config=/php-config
   make && make install

and to the configuration file /ext-taint.ini add:

   [taint]
   extension=“//taint.so"
   taint.enable = On

~~ Recap of discussion so far

Administrative:
- Any new feature requests should be for php 7.1 and not php 7.0
- Taint should not be written to the logs in the default configuration as is 
true for NOTICE level logs
Pros:
- Taint helps to refactor legacy/large code bases
- Taint helps to identify entire classes of programming bugs (such as SQL 
injections)
- Security experts suggest taint as a useful tool
- Including taint as a first class feature will allow for it to be available in 
future linux distribution packages of php
Cons:
- Taint could harm inexperienced or unmindful programmers; improper filtering 
of a tainted variable could be falsely validated via a taint feature.
- Taint may promote inexperienced programers to add bad sanitization, reducing 
their code quality.

~~ Adding to the discussion

Taint is a great feature for identifying where no sanitization is occurring (as 
opposed to incorrect sanitization).
Incorrect sanitization is not addressed by taint and can currently only be 
addressed via code audit; This situation is analogous to what taint will 
improve for the ‘no sanitization’ case.
Taint will not suggest a contextually correct sanitization, but arming a 
programmer with the knowledge of where to consider sanitization should at worst 
promote thought and will at best contribute to improved security globally.

The inclusion of taint does not worsen the ‘incorrect sanitization’ case.
The inclusion of taint does not hinder future RFCs from addressing the 
‘incorrect sanitization’ case.

It would be fantastic to be able to call untaint() without having to first 
check if the module is loaded (as could be the case in a staging versus 
production environment configuration for example).

~~ Moving forward

As discussion seems to have died out, I would like to propose moving to the 
next stage for inclusion of taint as a first class feature of php 7.1.

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

Re: [PHP-DEV] Immutable modifier

[Chris Riley]

On Tue, 17 Nov 2015, 02:07 Andrea Faulds  wrote:

Hi,

Chris Riley wrote:
>
> There has been a lot of interest recently (eg psr-7) in immutable data.
I'm
> considering putting an RFC together to add language support for
immutables:
>

I wonder if immutable classes are really the right way to go. Immutable
reference types with manual copying are somewhat alien to PHP: instead,
the language has used copy-on-write mutable value types for arrays and
strings, and prior to PHP 5, objects.

Copy-on-write value types have all the benefits immutable types do. They
can't be mutated at a distance unless you make a reference to them,
trees made of them can be compared for equality with just ===, etc.

But they also have benefits that immutable types lack. They're easier to
work with, because you can directly mutate them like everyone's used to
doing: no messing around with withFooBar() and withoutFooBar(), you just
set foobar or remove it directly. And PHP handles the duplication of
objects for you implicitly, so there's far less code to write.

Unfortunately, PHP 5 got rid of PHP 4's value type objects and replaced
them with reference type objects. But we could always introduce a way to
get value type objects again. How about a `struct` keyword? It would be
equivalent to `class`, but produce a value type rather than a reference
type.

Any thoughts?

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

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



My main motivation for this was for event objects when doing event sourcing
- they are by definition unchangeable after creation. That said,
considering the wider use case there does seem to be a need to emulate the
with* functions.

One option would be to hide the messy constructor call within user defined
methods, but that would add a lot of boilerplate - something I was wanting
to reduce not increase.

I can't think of a clean easy way to add with* functionality at a language
level without even more magic (parameter skipping?)

As for setter injection - my initial proposal would support that - a
property declared immutable allows itself to be set - once.

If someone can give my wiki account rfc karma I can write this up so far
too help focus discussion.

~C