Re: [PHP-DEV] File system watcher/monitoring

[Pierre Joye]

hi Sanford,

On Fri, Feb 15, 2013 at 8:35 AM, Sanford Whiteman
 wrote:
>> There are native APIs for that (read: non .net, aka C) on Windows
>
> Well aware of that. The EXE does use the Win32 API, not a .NET
> wrapper. I've used that API ever since it's been documented.

Right, but these APIs can and should be used within the extension. I
have a couple private extensions using them.

>> using an external process for this purpose would be horrible, in all
>> possible ways.
>
> Well, yeah, that's my very point... having the engine/extension do
> this is the proper direction (I only use this hack to check completion
> of some scheduled tasks, it's all private).
>
> Stas says typical PHP apps don't have a need for file system hooks.

Well, I tend to slightly disagree with him here, that's something,
along with a better locking API and another for shared memory (shared,
process or thread) should be available.

> Sure, long-polling may not be good with thread-per-process webservers,
> but those aren't the only PHP environments in the wild. Once you
> accept that people already roll out long-polling back ends with PHP,
> the next step is to minimize the check-sleep-loop hackery and offer
> true event-driven alternatives when possible.

Events based APIs are already part of the PHP ecosystems. I see no
problem here, even within a request. However there are some technical
issues to solve, APIs and how they should work outside or between
requests.

> Nothing I'm saying is controversial.

That's a tech discussion, I do not see controversy here but exchange
of views or arguments, that's how we move forward :)

Cheers,
-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

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

[PHP-DEV] Re: O+ 1st results

[Jan Ehrhardt]

Hi Pierre,

Pierre Joye in php.internals (Fri, 15 Feb 2013 07:21:00 +0100):
>http://windows.php.net/downloads/snaps/ostc/pftt/perf/results-20130213-5.4.11-5.5.0devvc11.html
>
>We did not update the templates for the report, please read the table as:
>
>- No Cache:
>  . 5.5 VC11 PGO vs 5.4 VC9  PGO
>- Wincache
>  . 5.4 PGO + Wincache vs 5.5 PGO + O+
>
>TS mode is totally broken using O+, so ignore this column.

Is that the column 5.5.0devvc11 under APC -igbinary? I have a Drupal7
site running on my devserver (W2K8, Apache 2.4.3, PHP 5.3.21 TS as
mod_fcgid) and do not get the idea it is running at one third (21.9 /
69.4) of the speed of the same site without any cache at all.

Do you have an idea what goes wrong?

>Mediawiki is slower because it does not support yet O+ for usercache,
>along other things.

Is the same the case with Symfony?

Jan

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

Re: [PHP-DEV] Re: O+ 1st results

[Pierre Joye]

On Fri, Feb 15, 2013 at 9:45 AM, Jan Ehrhardt  wrote:
> Hi Pierre,
>
> Pierre Joye in php.internals (Fri, 15 Feb 2013 07:21:00 +0100):
>>http://windows.php.net/downloads/snaps/ostc/pftt/perf/results-20130213-5.4.11-5.5.0devvc11.html
>>
>>We did not update the templates for the report, please read the table as:
>>
>>- No Cache:
>>  . 5.5 VC11 PGO vs 5.4 VC9  PGO
>>- Wincache
>>  . 5.4 PGO + Wincache vs 5.5 PGO + O+
>>
>>TS mode is totally broken using O+, so ignore this column.
>
> Is that the column 5.5.0devvc11 under APC -igbinary? I have a Drupal7
> site running on my devserver (W2K8, Apache 2.4.3, PHP 5.3.21 TS as
> mod_fcgid) and do not get the idea it is running at one third (21.9 /
> 69.4) of the speed of the same site without any cache at all.

No, but O+ is broken right now in ZTS, it makes no sense to do further
testing before it works for more than 0.5 request ;)

But running TS builds in FCGI reduces drastically the issues due to
thread safety bugs, while it makes no sense to use them, fcgi and the
likes should rely on NTS builds. ZTS will do all kind of locks where
it is absolutely not required, that explains at least 15-20% of the
perf drop, virtual paths cover the rest.

> Do you have an idea what goes wrong?

Not yet, Dmitry told me that he will work on it today.

>>Mediawiki is slower because it does not support yet O+ for usercache,
>>along other things.
>
> Is the same the case with Symfony?

no, MediaWiki caching modules only support APC or Wincache so far.


Cheers,
-- 
Pierre

@pierrejoye

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

Re: [PHP-DEV] Re: O+ 1st results

[Jan Ehrhardt]

Pierre Joye in php.internals (Fri, 15 Feb 2013 09:54:03 +0100):
>On Fri, Feb 15, 2013 at 9:45 AM, Jan Ehrhardt  wrote:

>>>http://windows.php.net/downloads/snaps/ostc/pftt/perf/results-20130213-5.4.11-5.5.0devvc11.html
>>
>> Is that the column 5.5.0devvc11 under APC -igbinary? I have a Drupal7
>> site running on my devserver (W2K8, Apache 2.4.3, PHP 5.3.21 TS as
>> mod_fcgid) and do not get the idea it is running at one third (21.9 /
>> 69.4) of the speed of the same site without any cache at all.
>
>No, but O+ is broken right now in ZTS, it makes no sense to do further
>testing before it works for more than 0.5 request ;)
>
>But running TS builds in FCGI reduces drastically the issues due to
>thread safety bugs, while it makes no sense to use them, fcgi and the
>likes should rely on NTS builds. ZTS will do all kind of locks where
>it is absolutely not required, that explains at least 15-20% of the
>perf drop, virtual paths cover the rest.

I will try to compare the same site side-by-side with different configs.
The dev-server has 4 IPv4=adresses which gives a lot of config options.

>>>Mediawiki is slower because it does not support yet O+ for usercache,
>>>along other things.
>>
>> Is the same the case with Symfony?
>
>no, MediaWiki caching modules only support APC or Wincache so far.

Is the performance drop for Symfony in the Wincache test due to the fact
that wincache is optimized for IIS or are there other reasons?

Jan

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

Re: [PHP-DEV] Re: O+ 1st results

[Pierre Joye]

On Fri, Feb 15, 2013 at 10:08 AM, Jan Ehrhardt  wrote:
> Pierre Joye in php.internals (Fri, 15 Feb 2013 09:54:03 +0100):
>>On Fri, Feb 15, 2013 at 9:45 AM, Jan Ehrhardt  wrote:
>
http://windows.php.net/downloads/snaps/ostc/pftt/perf/results-20130213-5.4.11-5.5.0devvc11.html
>>>
>>> Is that the column 5.5.0devvc11 under APC -igbinary? I have a Drupal7
>>> site running on my devserver (W2K8, Apache 2.4.3, PHP 5.3.21 TS as
>>> mod_fcgid) and do not get the idea it is running at one third (21.9 /
>>> 69.4) of the speed of the same site without any cache at all.
>>
>>No, but O+ is broken right now in ZTS, it makes no sense to do further
>>testing before it works for more than 0.5 request ;)
>>
>>But running TS builds in FCGI reduces drastically the issues due to
>>thread safety bugs, while it makes no sense to use them, fcgi and the
>>likes should rely on NTS builds. ZTS will do all kind of locks where
>>it is absolutely not required, that explains at least 15-20% of the
>>perf drop, virtual paths cover the rest.
>
> I will try to compare the same site side-by-side with different configs.
> The dev-server has 4 IPv4=adresses which gives a lot of config options.
>
Mediawiki is slower because it does not support yet O+ for usercache,
along other things.
>>>
>>> Is the same the case with Symfony?
>>
>>no, MediaWiki caching modules only support APC or Wincache so far.
>
> Is the performance drop for Symfony in the Wincache test due to the fact
> that wincache is optimized for IIS or are there other reasons?

Did not analyze it yet.

WinCache is not IIS optimized but FastCGI (read: process based). Also
we did not enabled file IO cache, which could bring it up in line.
But as neither APC or O+ have it, it cannot be compared.

Cheers,
-- 
Pierre

@pierrejoye

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

Re: [PHP-DEV] Re: O+ 1st results

[Damien Tournoud]

I assume that something is functionally wrong on Symfony/O+:

Symfony, IIS, cache, PHP5.5.0devvc11: 2195
Symfony, IIS, cache, PHP5.5.0devvc11: 1919
Symfony, IIS, cache, PHP5.5.0devvc11: 2127


There was a previous report that Twig did not work at all with
optimizations enabled.

Damien

On Fri, Feb 15, 2013 at 10:15 AM, Pierre Joye  wrote:
> On Fri, Feb 15, 2013 at 10:08 AM, Jan Ehrhardt  wrote:
>> Pierre Joye in php.internals (Fri, 15 Feb 2013 09:54:03 +0100):
>>>On Fri, Feb 15, 2013 at 9:45 AM, Jan Ehrhardt  wrote:
>>
>
http://windows.php.net/downloads/snaps/ostc/pftt/perf/results-20130213-5.4.11-5.5.0devvc11.html

 Is that the column 5.5.0devvc11 under APC -igbinary? I have a Drupal7
 site running on my devserver (W2K8, Apache 2.4.3, PHP 5.3.21 TS as
 mod_fcgid) and do not get the idea it is running at one third (21.9 /
 69.4) of the speed of the same site without any cache at all.
>>>
>>>No, but O+ is broken right now in ZTS, it makes no sense to do further
>>>testing before it works for more than 0.5 request ;)
>>>
>>>But running TS builds in FCGI reduces drastically the issues due to
>>>thread safety bugs, while it makes no sense to use them, fcgi and the
>>>likes should rely on NTS builds. ZTS will do all kind of locks where
>>>it is absolutely not required, that explains at least 15-20% of the
>>>perf drop, virtual paths cover the rest.
>>
>> I will try to compare the same site side-by-side with different configs.
>> The dev-server has 4 IPv4=adresses which gives a lot of config options.
>>
>Mediawiki is slower because it does not support yet O+ for usercache,
>along other things.

 Is the same the case with Symfony?
>>>
>>>no, MediaWiki caching modules only support APC or Wincache so far.
>>
>> Is the performance drop for Symfony in the Wincache test due to the fact
>> that wincache is optimized for IIS or are there other reasons?
>
> Did not analyze it yet.
>
> WinCache is not IIS optimized but FastCGI (read: process based). Also
> we did not enabled file IO cache, which could bring it up in line.
> But as neither APC or O+ have it, it cannot be compared.
>
> Cheers,
> --
> Pierre
>
> @pierrejoye
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Re: [PHP-DEV] Re: O+ 1st results

[Damien Tournoud]

On Fri, Feb 15, 2013 at 9:54 AM, Pierre Joye  wrote:
>
> >>Mediawiki is slower because it does not support yet O+ for usercache,
> >>along other things.
> >
> > Is the same the case with Symfony?
>
> no, MediaWiki caching modules only support APC or Wincache so far.

As far as I understand, O+ doesn't have any user caching support, right?

So the comparison needs to be with user caching disabled in Mediawiki
when running with APC or Wincache.

Damien

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

Re: [PHP-DEV] Re: O+ 1st results

[Paul Dragoonis]

On Fri, Feb 15, 2013 at 9:23 AM, Damien Tournoud  wrote:

> On Fri, Feb 15, 2013 at 9:54 AM, Pierre Joye  wrote:
> >
> > >>Mediawiki is slower because it does not support yet O+ for usercache,
> > >>along other things.
> > >
> > > Is the same the case with Symfony?
> >
> > no, MediaWiki caching modules only support APC or Wincache so far.
>
> As far as I understand, O+ doesn't have any user caching support, right?
>
> So the comparison needs to be with user caching disabled in Mediawiki
> when running with APC or Wincache.
>

Hi Damien,

No, O+ doesn't have user level caching, it's only for opcode caching. It
was discussed that APC should continue to provide user level caching.


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

[PHP-DEV] PHP 5.5 upcoming roadmap

[Julien Pauli]

Hello everyone,

As you may know, Zend recently open sourced ZendOptimizer+ with a PHP
Licence.
We are planning to merge it to PHP5.5 Core (discussions on Mailing lists
and IRC) and have it bundled with PHP5.5 final release stable.

For this, we need to merge new code to 5.5 as well as have a testing period
for this new feature.

As RMs, David and I decided then to change the original release plans for
5.5.
5.5 will benefit a new alpha (5th), on thu 21st Feb. ZO+ will be merged for
this alpha.
Then, we are planning to release the first beta on March the 7th. We remind
you that beta stage means feature freeze. We won't accept new features code
after the first beta is released.

This is a (about) one month delay compared to original planning (first beta
was planned for Feb 7th), but it is needed.

You will find more information about ZO+ integration on the wiki, at
https://wiki.php.net/rfc/optimizerplus

Julien Pauli and David Soria Parra

Re: [PHP-DEV] File system watcher/monitoring

[Victor Berchet]

On 02/14/2013 03:03 PM, Ivan Enderlin @ Hoa wrote:

Hi internal,

A missing feature in PHP is a file system watcher/monitoring available 
for almost all platforms. On Linux, we have inotify (available in PHP 
through pecl/inotify), on Mac OS X, we have /dev/fsevents (not 
available in PHP, since we need ioctl to do that in pure PHP —and 
sudo—, no C extension needed), on FreeBSD, we have FAM, and on 
Windows, we have FileSystemWatcher in .NET. All major platforms have a 
solution ready to use.


By now, if we didn't use these solutions, we should use a finder 
(thanks to RecursiveIteratorIterator and DirectoryIterator in SPL) 
that runs every n seconds and compute a diff with the previous run. 
This solution works fine for a small set of files but it can slow for 
a big one. This is just a tricky solution, not a proper one.


Possible domains where it is needed: test, CI, log, file transfering, 
security etc.


Is it possible to have such a feature landing in PHP (core if karma 
allows it)? or do you want such a feature?


Best regards :-).


Ivan,

Everzet has started to build a client side solution[1]

Hopefuly he will have time to update the PR with what is remaining to do 
soon[2]


[1] https://github.com/symfony/symfony/pull/4605
[2] https://twitter.com/everzet/status/302381248620408832

Cheers,
Victor

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

Re: [PHP-DEV] PHP 5.5 upcoming roadmap

[Patrick ALLAERT]

2013/2/15 Julien Pauli :
> Hello everyone,
>
> As you may know, Zend recently open sourced ZendOptimizer+ with a PHP
> Licence.
> We are planning to merge it to PHP5.5 Core (discussions on Mailing lists
> and IRC) and have it bundled with PHP5.5 final release stable.

Correct me if I am wrong, but this is part of the following RFC:
https://wiki.php.net/rfc/optimizerplus which contains some voting
options.
Isn't a vote supposed to happen *before* it is actually merged or did
I miss something (#pecl ?).

Patrick

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

Re: [PHP-DEV] File system watcher/monitoring

[Ivan Enderlin @ Hoa]

Hi Victor,

On 15/02/13 12:43, Victor Berchet wrote:


On 02/14/2013 03:03 PM, Ivan Enderlin @ Hoa wrote:

Hi internal,

A missing feature in PHP is a file system watcher/monitoring 
available for almost all platforms. On Linux, we have inotify 
(available in PHP through pecl/inotify), on Mac OS X, we have 
/dev/fsevents (not available in PHP, since we need ioctl to do that 
in pure PHP —and sudo—, no C extension needed), on FreeBSD, we have 
FAM, and on Windows, we have FileSystemWatcher in .NET. All major 
platforms have a solution ready to use.


By now, if we didn't use these solutions, we should use a finder 
(thanks to RecursiveIteratorIterator and DirectoryIterator in SPL) 
that runs every n seconds and compute a diff with the previous run. 
This solution works fine for a small set of files but it can slow for 
a big one. This is just a tricky solution, not a proper one.


Possible domains where it is needed: test, CI, log, file transfering, 
security etc.


Is it possible to have such a feature landing in PHP (core if karma 
allows it)? or do you want such a feature?


Best regards :-).


Ivan,

Everzet has started to build a client side solution[1]

Hopefuly he will have time to update the PR with what is remaining to 
do soon[2]
I have read your conversation on Twitter. Everzet uses inotify or a 
recursiveiterator as a fallback, as suggested in my first mail, but this 
cannot be extended to FSEvents, FAM etc. A solution in pure PHP is not 
possible for technical reasons (we need ioctl to read from 
/dev/fsevents, or we need a low-level C program for Windows, BSD etc.). 
That's my point here :-).
Of course, “tricky” solutions exist on the Web, like the one proposed by 
Everzet. I did one and you can find many others, but they are 
“incomplete” or “unefficient” most of the times (note the quotes here, 
it depends of the context of use).


Cheers.

--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/



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

Re: [PHP-DEV] File system watcher/monitoring

[Ivan Enderlin @ Hoa]

On 14/02/13 18:02, Paul Dragoonis wrote:

On Thu, Feb 14, 2013 at 5:00 PM, Patrick ALLAERT wrote:


2013/2/14 Ivan Enderlin @ Hoa :

I have written: “On Linux, we have inotify (available in PHP through
pecl/inotify)”, so yup, I know for inotify :-). I propose to gather all
these API and give a proper one to the end-user.

If you are doing so, I would suggest you to create this as a C
library, that way you could bring that feature to any
applications/languages and you would only have to create a bridge as a
PECL extension.


and to carry on from Patrick's point, it would probably be cleaner to do it
this way so your library wouldn't need to work around PHP stuff.
Actually, I have already considered this approach, but to make a clean 
and portable C version, it might be better to use external existing 
libraries (e.g. for events). This might create hard dependencies and 
could be embarassing for a PECL extension, no?


Thoughts?

--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/



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

Re: [PHP-DEV] File system watcher/monitoring

[Ivan Enderlin @ Hoa]

On 15/02/13 14:20, Sebastian Krebs wrote:

2013/2/15 Ivan Enderlin @ Hoa 


Hi Stas,


On 14/02/13 22:37, Stas Malyshev wrote:


Hi!

  A missing feature in PHP is a file system watcher/monitoring available

for almost all platforms. On Linux, we have inotify (available in PHP
through pecl/inotify), on Mac OS X, we have /dev/fsevents (not available
in PHP, since we need ioctl to do that in pure PHP —and sudo—, no C
extension needed), on FreeBSD, we have FAM, and on Windows, we have
FileSystemWatcher in .NET. All major platforms have a solution ready to
use.


I think it'd be great to have a library with unified interface and an
extension that uses it. However, I'm not sure if these libraries are
useful in common php use case - short-lived requests. Could I get the
changes since the last request? Or is it useful only for long-running
persistent processes?


It is only useful for long-running processes.

For example when you are writting tests: at each modifications, you would
like to re-run or re-generate tests. In this case, you have a daemon that
watches files changes and executes a command when needed.


Why do you need PHP for this?
http://stackoverflow.com/questions/3283228/bash-execute-script-on-file-save#answer-3283390

I don't understand your point.

--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/



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

Re: [PHP-DEV] File system watcher/monitoring

[Sebastian Krebs]

2013/2/15 Ivan Enderlin @ Hoa 

> On 15/02/13 14:20, Sebastian Krebs wrote:
>
>> 2013/2/15 Ivan Enderlin @ Hoa 
>>
>>  Hi Stas,
>>>
>>>
>>> On 14/02/13 22:37, Stas Malyshev wrote:
>>>
>>>  Hi!

   A missing feature in PHP is a file system watcher/monitoring available

> for almost all platforms. On Linux, we have inotify (available in PHP
> through pecl/inotify), on Mac OS X, we have /dev/fsevents (not
> available
> in PHP, since we need ioctl to do that in pure PHP —and sudo—, no C
> extension needed), on FreeBSD, we have FAM, and on Windows, we have
> FileSystemWatcher in .NET. All major platforms have a solution ready to
> use.
>
>  I think it'd be great to have a library with unified interface and an
 extension that uses it. However, I'm not sure if these libraries are
 useful in common php use case - short-lived requests. Could I get the
 changes since the last request? Or is it useful only for long-running
 persistent processes?

  It is only useful for long-running processes.
>>>
>>> For example when you are writting tests: at each modifications, you would
>>> like to re-run or re-generate tests. In this case, you have a daemon that
>>> watches files changes and executes a command when needed.
>>>
>>>  Why do you need PHP for this?
>> http://stackoverflow.com/**questions/3283228/bash-**
>> execute-script-on-file-save#**answer-3283390
>>
> I don't understand your point.


For the use-case you described here a PHP-implementation is not required,
because you can use the system-tools to invoke PHPUnit. In fact you don't
need a daemon at all ;)


>
>
> --
> Ivan Enderlin
> Developer of Hoa
> http://hoa-project.net/
>
> PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
> http://disc.univ-fcomte.fr/ and http://www.inria.fr/
>
> Member of HTML and WebApps Working Group of W3C
> http://w3.org/
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
github.com/KingCrunch

Re: [PHP-DEV] File system watcher/monitoring

[Ivan Enderlin @ Hoa]

On 15/02/13 14:29, Sebastian Krebs wrote:

2013/2/15 Ivan Enderlin @ Hoa 


On 15/02/13 14:20, Sebastian Krebs wrote:


2013/2/15 Ivan Enderlin @ Hoa 

  Hi Stas,


On 14/02/13 22:37, Stas Malyshev wrote:

  Hi!

   A missing feature in PHP is a file system watcher/monitoring available


for almost all platforms. On Linux, we have inotify (available in PHP
through pecl/inotify), on Mac OS X, we have /dev/fsevents (not
available
in PHP, since we need ioctl to do that in pure PHP —and sudo—, no C
extension needed), on FreeBSD, we have FAM, and on Windows, we have
FileSystemWatcher in .NET. All major platforms have a solution ready to
use.

  I think it'd be great to have a library with unified interface and an

extension that uses it. However, I'm not sure if these libraries are
useful in common php use case - short-lived requests. Could I get the
changes since the last request? Or is it useful only for long-running
persistent processes?

  It is only useful for long-running processes.

For example when you are writting tests: at each modifications, you would
like to re-run or re-generate tests. In this case, you have a daemon that
watches files changes and executes a command when needed.

  Why do you need PHP for this?

http://stackoverflow.com/**questions/3283228/bash-**
execute-script-on-file-save#**answer-3283390


I don't understand your point.


For the use-case you described here a PHP-implementation is not required,
because you can use the system-tools to invoke PHPUnit. In fact you don't
need a daemon at all ;)
It is an example :-). I could reply: why do you need need PHPUnit, there 
is so much other tools ;-).


Well, you get the point. These is a lot of applications.

--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/



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

Re: [PHP-DEV] PHP 5.5 upcoming roadmap

[Sherif Ramadan]

On Fri, Feb 15, 2013 at 7:19 AM, Patrick ALLAERT wrote:

> 2013/2/15 Julien Pauli :
> > Hello everyone,
> >
> > As you may know, Zend recently open sourced ZendOptimizer+ with a PHP
> > Licence.
> > We are planning to merge it to PHP5.5 Core (discussions on Mailing lists
> > and IRC) and have it bundled with PHP5.5 final release stable.
>
> Correct me if I am wrong, but this is part of the following RFC:
> https://wiki.php.net/rfc/optimizerplus which contains some voting
> options.
> Isn't a vote supposed to happen *before* it is actually merged or did
> I miss something (#pecl ?).
>
>
I must have missed the discussion where the voting was skipped, but I am
kind of concerned that such a big change is going to make it into a feature
frozen version (where we won't be able to say this should be removed (BC
and all that)) without a vote.

I'm not necessarily saying I'm opposed to this addition as I think it's
great, but I'd like an opportunity to test it out first and play around
with it for a few weeks. It's hard to find major problems without a lot of
testing and then our biggest problem is always BC. We always find BC to be
one of the biggest reasons to hold off on changing stuff.

I have looked at the code but in my experience you don't find real bugs
until you start testing code you already have working in production on
these patches to find the really annoying bugs.


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

RE: [PHP-DEV] Re: O+ 1st results

[Stephen Zarkos]

Hello Damien,

> -Original Message-
> From: Damien Tournoud [mailto:d...@damz.org]
> 
> I assume that something is functionally wrong on Symfony/O+:
> 
> Symfony, IIS, cache, PHP5.5.0devvc11: 2195 Symfony, IIS, cache,
> PHP5.5.0devvc11: 1919 Symfony, IIS, cache, PHP5.5.0devvc11: 2127
> 

Yes, that is correct.  We've since corrected the issue for symfony and ran 
another test with better results.  You can always find our test results at the 
following page (organized by date, top to bottom):  
http://windows.php.net/downloads/snaps/ostc/pftt/perf/

We'll be running these tests constantly.  The next run should also include 
fixes for ZTS and other things, so please feel free to keep an eye on the 
latest results and let me know if you have questions.

Thanks!

Stephen A. Zarkos
Microsoft
Open Source Technology Center
Office:  425-704-0422
stephen.zar...@microsoft.com





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

Re: [PHP-DEV] PHP 5.5 upcoming roadmap

[Lars Strojny]

Hi Julien,

Am 15.02.2013 um 13:05 schrieb Julien Pauli :

> Hello everyone,
> 
> As you may know, Zend recently open sourced ZendOptimizer+ with a PHP
> Licence.
> We are planning to merge it to PHP5.5 Core (discussions on Mailing lists
> and IRC) and have it bundled with PHP5.5 final release stable.

I'm sorry, but you must be kidding doing such a change and skipping the RFC 
process altogether. This will seriously hurt the acceptance of the whole RFC 
process and there won’t be a good argument against people just committing 
random changes without an RFC. How should I convince somebody with a working 
pull request to go ahead and deal with an RFC when we introduce changes like 
that "just like that".

Can we please stop the process insanity and stick to our own rules (or change 
them in a transparent way).

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

Re: [PHP-DEV] PHP 5.5 upcoming roadmap

[David Soria Parra]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

so just to make this sure. We are NOT skipping the RFC. we are
planning to merge it before beta1 IN CASE the RFC get's accepted. I
believe a op cache is really important for the overall acceptance so I
hope the RFC gets accepted. Nevertheless it's up to the author of the
RFC to call for votes, but we as RMs just wanted to stretch the actual
release dates as I think this RFC is important enough to justify such
a step.

David

Am 15.02.13 19:08, schrieb Lars Strojny:
> Hi Julien,
> 
> Am 15.02.2013 um 13:05 schrieb Julien Pauli :
> 
>> Hello everyone,
>> 
>> As you may know, Zend recently open sourced ZendOptimizer+ with a
>> PHP Licence. We are planning to merge it to PHP5.5 Core
>> (discussions on Mailing lists and IRC) and have it bundled with
>> PHP5.5 final release stable.
> 
> I'm sorry, but you must be kidding doing such a change and skipping
> the RFC process altogether. This will seriously hurt the acceptance
> of the whole RFC process and there won’t be a good argument against
> people just committing random changes without an RFC. How should I
> convince somebody with a working pull request to go ahead and deal
> with an RFC when we introduce changes like that "just like that".
> 
> Can we please stop the process insanity and stick to our own rules
> (or change them in a transparent way).
> 
> Thanks, Lars
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRHnsjAAoJEKSanlo0ToXKmXAP/AuKTYfcm3PZdrOu9nqDkg8x
IjnsY5pMybDTbkJtLw96DT+5Zz24t9BdwBPwTRkKccLiYGavCQvV+ewdNUMEFrv7
kbuyi6tgRbB/aUpocKXbzq5CRk19YcIZr3E4HXpeMHcNhXGbFRmXvk8yMUWlTGMn
Fsf6v9bs+4d/uCaSMr2jS56KgDTn9pseAbeDumj3L+EAZYF+k/lz0YuxNC7X3EUv
HclKiPBLroaYz0q4Yg+BHuBsCgkhGnzwxNlYfkCPHh8mZZFxUtcIkONgILgxsGMA
+ik51JzspZRkdvr+TpvE6Va5O52i3C31wxKelr4f2+dgDO7v28tqOxrOHYVZgpdY
NK3GOYDgp1YgphY0CY/J0IrK2yLjdqois7qynuyAwP7DxE/ytz6HFs4UuzPdM6Ry
sFXua/L5JFzHHO4jU1x47BDM/Blre2COQaMdB1GE2hgFIjKqU5cQRHxMG6VzGCct
UiWik8/1sLQKoMFQnSMBHbidlYbDCKd4kW2dyKjKw9Ok3MfW08VPZ/SBJNB2RDYP
aYD4OcVe9SE9kuJEP0sxs9f/s4xMmkiP6AYa/2e2L4UqfoT0bo20HrrA50h0lKXb
hkj/yOWB9f6qy3qUhDK5EdbSPK5i18cS5jWcseXLjHlE/xADWGrTyjAg2flaKAQT
xF5/opO8pfoi4PY6osQT
=iZJN
-END PGP SIGNATURE-

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

Re: [PHP-DEV] PHP 5.5 upcoming roadmap

[Lars Strojny]

Hi David,

thanks for the clarification, sounds like a plan :-) I'm not opposed to 
including O+, quite the opposite but I want us to stick to our process.

cu,
Lars

Am 15.02.2013 um 19:14 schrieb David Soria Parra :

[...]

>> I'm sorry, but you must be kidding doing such a change and skipping
>> the RFC process altogether. This will seriously hurt the acceptance
>> of the whole RFC process and there won’t be a good argument against
>> people just committing random changes without an RFC. How should I
>> convince somebody with a working pull request to go ahead and deal
>> with an RFC when we introduce changes like that "just like that".
>> 
>> Can we please stop the process insanity and stick to our own rules
>> (or change them in a transparent way).
>> 
>> Thanks, Lars
>> 
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (Darwin)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQIcBAEBAgAGBQJRHnsjAAoJEKSanlo0ToXKmXAP/AuKTYfcm3PZdrOu9nqDkg8x
> IjnsY5pMybDTbkJtLw96DT+5Zz24t9BdwBPwTRkKccLiYGavCQvV+ewdNUMEFrv7
> kbuyi6tgRbB/aUpocKXbzq5CRk19YcIZr3E4HXpeMHcNhXGbFRmXvk8yMUWlTGMn
> Fsf6v9bs+4d/uCaSMr2jS56KgDTn9pseAbeDumj3L+EAZYF+k/lz0YuxNC7X3EUv
> HclKiPBLroaYz0q4Yg+BHuBsCgkhGnzwxNlYfkCPHh8mZZFxUtcIkONgILgxsGMA
> +ik51JzspZRkdvr+TpvE6Va5O52i3C31wxKelr4f2+dgDO7v28tqOxrOHYVZgpdY
> NK3GOYDgp1YgphY0CY/J0IrK2yLjdqois7qynuyAwP7DxE/ytz6HFs4UuzPdM6Ry
> sFXua/L5JFzHHO4jU1x47BDM/Blre2COQaMdB1GE2hgFIjKqU5cQRHxMG6VzGCct
> UiWik8/1sLQKoMFQnSMBHbidlYbDCKd4kW2dyKjKw9Ok3MfW08VPZ/SBJNB2RDYP
> aYD4OcVe9SE9kuJEP0sxs9f/s4xMmkiP6AYa/2e2L4UqfoT0bo20HrrA50h0lKXb
> hkj/yOWB9f6qy3qUhDK5EdbSPK5i18cS5jWcseXLjHlE/xADWGrTyjAg2flaKAQT
> xF5/opO8pfoi4PY6osQT
> =iZJN
> -END PGP SIGNATURE-
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


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

Re: [PHP-DEV] Zend Optimizer+ Source Code now available

[Terry Ellison]

On 15/02/13 01:59, Stas Malyshev wrote:

(A) The op-code optimization should be integrated into the core compiler
and enabled through a GC(compiler_option) to be available to *any*
opcode cache -- or to the application designer (by exposing these
options through an INI directive.

Most optimizations would not give perceivable benefit unless the
optimized code is run many times. So enabling it without opcode cache
would not produce very big benefit. But yes, in theory these code parts
can live separately and they don't actually need each other.
My point here is that APC and the other opcode caches would also benefit 
from these optimizations; they really belong to the compiler and not to 
an opcode accelerator.  Also yes, this type of optimisation usually has 
no net benefit unless  #runs / compile is much greater than one, however 
there are scenarios (e.g. some nasty iteration intensive batch process) 
where taking the hit on optimisation still produces a net runtime saving.

that support it).  A Zend opcode cache belongs firmly in the Zend world
and shouldn't be a PHP extension.

I must say I don't understand this conclusion.
Put simply PHP extensions should only reference the APIs exposed in the 
php headers.  Zend has its own interface and extensions and since a Zend 
Opcode cache is SO intimately coupled with the Zend environment it makes 
sense to use a Zend extension to implement this.  The whole idea of 
opcode caching just isn't relevant to a Hiphop environment or even for 
that matter a CLR or Java one since this do their own internal caching 
anyway.



I also note some interesting difference in approaches between O+ and
APC, say for example:

1) in the handling of the ZEND_INCLUDE_OR_EVAL instruction where APC
patches the op handler and O+ does peephole opcode examination.  Both
these workarounds could be avoided by tidying up the scope of work in
the instruction code.

Could you explain this a bit more?
As I posted in a separate not to this list, I've am developing my own 
LPC extension, a fork of APC optimized for CLI and GCI use.  The dogma 
here is that there is no point in opcode caching because "performance 
isn't a driver".   Well my experience is that performance is always a 
driver  For example, just because your application is running on a 
shared service where UID enforced security must be applied and therefore 
some form of scalable per-UID execution environment must be used doesn't 
mean that you don't care about performance.  LPC still give a ~ 2x 
throughput improvement on MediaWiki for example.


I forked and rewrote this cache extension because I couldn't stretch the 
APC code to do what I want in a performant manner without breaking it.  
It's a demonstrator to help me understand the real issues here and to 
get to grips with the minutiae of PHP caching technologies.  I just 
don't see this ever getting to production, but I must admit that 
regressing some of this technologies onto O+ is an option that interests 
me because this does hold out the potential of a standard optimiser 
extension that supports all mainstream SAPIs.


Now to ZEND_INCLUDE_OR_EVAL.  My rationale here is that if the admin has 
specified a stat=0 (or equiv) option then this is a statement that the 
caches content and metadata can be trusted so there is no point in 
examining or reading source files.  However, in the case of the xxx_once 
variants of this instruction, the 
ZEND_INCLUDE_OR_EVAL_SPEC_CONST_HANDLER() does path resolution and in 
the case of first load opens the source stream.  Why?  Why not just 
leave examination of the source stream to the compile function?  LPC 
(like APC though for different reasons)  has to rehook the 
ZEND_INCLUDE_OR_EVAL_SPEC_CONST_HANDLE()  handler with a wrapper that 
does dynamic code modification to prevent this access occurring.  O+ 
adopts a different strategy.


LPC or APC having to walk through and essential patch over (private) 
static constant op_handler vectors is just plain horrible.  No, IMO the 
Zend architecture should be designed to support caching; it should 
present a proper clean interface that extensions such as O+ and APC 
implement; and the entire PHP test suite should be capable of being 
executed with a cache extension in place and a good cache should not 
introduce any test failures.


Sorry for the rant and I hope that I answered your Q :)

RE: [PHP-DEV] Zend Optimizer+ Source Code now available

[Zeev Suraski]

> -Original Message-
> From: Christopher Jones [mailto:christopher.jo...@oracle.com]
> Sent: Thursday, February 14, 2013 9:25 PM
> To: Zeev Suraski
> Cc: PHP internals
> Subject: Re: [PHP-DEV] Zend Optimizer+ Source Code now available
>
>
>
> On 02/14/2013 07:21 AM, Zeev Suraski wrote:
> >> Great to see.
> >>
> >> The README covers much of the content (and in more detail) that I
> >> previously wanted to see in the RFC.
> >
> > Excellent!
> >
> >> There are some things still missing from the RFC, though:
> >>
> >>- do you see Optimizer+ being enabled (if not in PECL) or disabled
> >> by
> >>  default, etc.
> >
> > I *think* we should strive to have it enabled by default, but it
> > should definitely be possible to turn it off too.  I guess that can be
> > another voting possibility - bundle & turn on by default (vs. just
> > bundle).
>
> To avoid too many voting choices, I think this can be decided outside the
> RFC
> process.

That depends on whether there'll be apparent consensus about it;  But it can
wait until after that RFC is approved, as a separate discussion and if
needed a separate vote.

> > We don't want to create any special cases in O+;  We would either take
> > care of integrating it by having slightly patching our O+ build, or
> > we'd add generalized facilities to O+ that will allow the loader to
> > interact with it directly (that would not be unique to the Zend loader
> > but could be used by any extension).  From my point of view, it's
> > nice-to-have to solve it before 5.5.0, not a must-have.
>
> This should still be stated in the RFC.  (The PHP community suffers from
> poor
> RFCs.  Since you are a leader in the PHP community, your RFC should set a
> good
> example.)

I think it goes beyond of the scope of the RFC but I'll add a bit of blurb
there.

> >>- There are still open questions in the RFC; these need to be closed
> >>  before voting.
> >
> > I think the only open question is integration with other modules, most
> > notably debuggers.  This is something we'd like to tackle sooner
> > rather than later, and I think it'll be easier to just go ahead and do
> > that now that the source code is available.  Any other open questions
> > that need answering?
>
> I think this should be reworded before the vote occurs.  I'm fine with
> leaving it
> under a heading "for future investigation", i.e. stating it won't happen
> in an
> initial release.

OK.

> >> Comments:
> >>
> >>- The README gives recommended parameters.  Taking that advice at
> >>  face value, I think these should be default settings.
> >
> > The default settings are designed to minimize the chance that an app
> > or a workflow - which worked fine w/o O+ - will suddenly fail after O+
> > is installed.  The 'recommended' settings are for max-performance.
> > You can view it like 'Safe' vs. 'Extreme' settings.  Personally I
> > think the default settings should be closer to the Safe ones...
>
> We can probably meet in the middle: leave the hard coded defaults as they
> currently are, and use those values in the php.ini-development examples.
> Php.ini-production can have the values recommended in the README.  (Giving
> the proposed php.ini settings is another thing the RFC should have...)

I actually think that the differences between the 'safe' and 'extreme'
settings don't correspond too well to development vs. production.  They
depend on the nature of the code/app you're running, and not on whether
you're developing the code or running it in production.

In my opinion, the defaults should be more or less the defaults we have
today, perhaps with minor tweaks - but with the guiding principle being that
they need to be *safe*, and minimize the chance that semantics would change
if you enable/disable O+.
The 'recommended' settings, which should really read 'extreme performance
settings', should end up in a documentation section, with nice clear
warnings about each and every setting and its potential impact on how apps
will perform.

I'll clarify that in the RFC.

> >>- Should the name reflect the code's main purpose (op-code caching),
> >>  and allowing a future use of "optimizer" for a more sophisticated
> >>  optimizer implementation?  Or do you see Optimizer+ being the
> >>  framework for such optimizations?
> >
> > O+ does perform some optimizations in addition to caching code, in a
> > O+ pretty
> > sophisticated manner actually (block optimizations).  Optimizations -
> > which can be expensive to carry out - are definitely a good fit with
> > an opcode cache, that ensures that you wouldn't have to do these
> > optimizations more than once.  I'm obviously subjective but I think
> > the name Optimizer+ does a good job at suggesting that it's both an
> > Optimizer
> but also something else.
> > Perhaps we should call it OptiCache? :)
>
> It seems a good time to disambiguate its relationship to any current or
> future
> Zend product.

Agreed.  Rasmus and I ping ponged some names

Re: [PHP-DEV] Zend Optimizer+ Source Code now available

[Stas Malyshev]

Hi!

> Put simply PHP extensions should only reference the APIs exposed in the
> php headers.  Zend has its own interface and extensions and since a Zend
> Opcode cache is SO intimately coupled with the Zend environment it makes
> sense to use a Zend extension to implement this.  The whole idea of

OK, I see. Well, the difference between Zend ext and PHP ext is not that
big, it's mostly just loading order and couple of hooks, of which I
think O+ really uses only op_array_handler, and this for optimization's
benefit - so if you separate optimization, I think O+ can live as PHP
extension, maybe. Not sure if it's worth the trouble though.

> Now to ZEND_INCLUDE_OR_EVAL.  My rationale here is that if the admin has
> specified a stat=0 (or equiv) option then this is a statement that the
> caches content and metadata can be trusted so there is no point in
> examining or reading source files.  However, in the case of the xxx_once
> variants of this instruction, the
> ZEND_INCLUDE_OR_EVAL_SPEC_CONST_HANDLER() does path resolution and in
> the case of first load opens the source stream.  Why?  Why not just

I see what you mean. I can't think of a reason why they are combined
now. Before realpath cache and separate path resolution functions that
was the only way to handle paths properly - since path can be resolved
differently by different streams, etc. I think giving a fresh look to
this API and seeing if we can improve it for 5.6, etc. would probably be
a good idea.

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

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

Re: [PHP-DEV] Re: O+ 1st results

[Ángel González]

On 15/02/13 10:25, Paul Dragoonis wrote:
> On Fri, Feb 15, 2013 at 9:23 AM, Damien Tournoud  wrote:
>> On Fri, Feb 15, 2013 at 9:54 AM, Pierre Joye  wrote:
>>> no, MediaWiki caching modules only support APC or Wincache so far. 
>> As far as I understand, O+ doesn't have any user caching support, right?
>>
>> So the comparison needs to be with user caching disabled in Mediawiki
>> when running with APC or Wincache.
> Hi Damien,
>
> No, O+ doesn't have user level caching, it's only for opcode caching. It
> was discussed that APC should continue to provide user level caching.

Does that mean that MediaWiki was using O+ for opcode cache and APC
for user level cache?
The best way to compare them would be to test both opcode caches with
a memcached server. No interaction between extensions, and no difference
in the connections to access the caching store. Moreover, if you are using
a production setup with multiple servers, you need to use memcached.


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

[PHP-DEV] Questions regarding DateTimeImmutable

[Nikita Popov]

Hi internals,

for PHP 5.5 a new DateTimeImmutable class was introduced, which is a
variant of DateTime, which has methods working on a clone of the original
object.

There was no RFC on this and some of the design decisions are a bit
uncleared to me, so I figured I'd write a mail:

a) The DateTimeImmutable class extends the DateTime class. Why was this
done this way? Both classes are incompatible (as in the inheritance
violates LSP). E.g. if you hint against DateTime, then passing in
DateTimeImmutable will not work (as the behavior is different). The same
also applies the other way around (DateTime extending DateTimeImmutable).
Imho a mutable and an immutable variant of a class can't reasonably extend
from one another, so I'm not sure why this was done.

b) The DateTimeImmutable class is (method-wise) an exact copy of DateTime.
This makes for some rather weird method names for an immutable object. E.g.
there is DateTimeImmutable::modify, which to me seems quite contradictory.
There are also a lot of methods of the DateTimeImmutable::setTime form,
which also seems rather odd and confusing (how can I set something on an
immutable object?)

The DateTimeImmutable class was added to fix design issues with DateTime,
but the way it was implemented I think it just replaced one evil with
another one. Could we maybe reconsider this?

Nikita

RE: [PHP-DEV] Zend Optimizer+ Source Code now available

[Christopher Jones]

Hi Zeev,

I think people are keen to see Optimizer+ merged.  Hopefully the RFC
can set expectations clear on what the short-term steps will be, and
what the bigger picture might look like.  The middle-term tasks will
then work themselves out as we get to them (in true PHP fashion)

- What does "Integrate Optimizer+ into PHP, but don’t delay 5.5.0 for
  it" mean?  Does it mean:

   * Work really had to get it into PHP 5.5.0 with no delay to 5.5?
   * Include it in /ext "as-is", i.e. perhaps no ZTS support, or marked 
EXPERIMENTAL?
   * Include it in PHP 5.5.x where x > 0, when Optimizer+ is complete?

  The slippage of 5.5 is an issue to some people, so clarity here
  would be good.

  I believe the wider community is expecting the op-code cache to
  "just work", so if that's not the case, the RFC should communicate
  this clearly.  There's also the potential to damage Zend's
  reputation if what is released doesn't work well.

- What are your general thoughts about its integration architecture
  and the potential for alternative op-code caches to be used?  I know
  code can always be changed, but what (if any) design will happen
  from the start to make this easy?

- Regarding name choice, here are some: ZopCache, Cachze, RunCachze.

Chris

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

Re: [PHP-DEV] Questions regarding DateTimeImmutable

[Sanford Whiteman]

I think it was done to ease adoption even though it was known to
violate LSP. To quote Stas, "As for established practice, everybody
expects DateTime, so IMHO we should leave DateTime as base class even
though it's not strictly OO-pure."

This way does let users sub in DateTimeImmutable more easily and patch
over a ton of unintended -- maybe not even fully noted or understood
-- defects in their apps? I dunno.

I looked at the first discussion from late 2010 after Benjamin E.
sketched out the language addition and Larry G. suggested making them
siblings as opposed to subclassing, but those discussions seemed to
peter out and by the time Derick wrote the patch, the class model was
kind of accepted.

The discussion from 2012 is rather mild considering some pretty
disparate viewpoints are represented, viz. users don't care about
mutability vs. users have been coding as if DT were immutable.

-- Sandy


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

Re: [PHP-DEV] Questions regarding DateTimeImmutable

[Levi Morrison]

> I think it was done to ease adoption even though it was known to
> violate LSP. To quote Stas, "As for established practice, everybody
> expects DateTime, so IMHO we should leave DateTime as base class even
> though it's not strictly OO-pure."

I can see how easing adoption would be logical, but honestly I don't
think this will help.  Just because the outward API *looks* the same,
a DateTimeImmutable is NOT a drop in replacement for DateTime. I
honestly think that having one or the other inheriting from the other
isn't *just* an LSP violation: it's a really big one. It's so big I
don't think there's much worth of having them inherit; I dare say it
would hurt it.

> This way does let users sub in DateTimeImmutable more easily and patch
> over a ton of unintended -- maybe not even fully noted or understood
> -- defects in their apps? I dunno.

Exactly.

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