Re: [PHP-DEV] Official Twitter Account

[Trevor Suarez]

On Thu, Dec 6, 2018 at 11:29 AM Sara Golemon  wrote:

> On Thu, Dec 6, 2018 at 12:14 PM Nikita Popov  wrote:
>
>> Given that the PHP 7.3 release announcement is somewhat more significant
>> than our usual maintenance releases, maybe that one could be done
>> separately?
>>
>> Given that the migration guide link is currently pointing at dead air,
> I'll probably give Christoph some time to fix that.
> http://php.net/manual/en/migration73.php
>
> -Sara
>

Yea, I noticed that too. I also noticed that all of the feature/change
links on the release announcement page 
are linked to GitHub anchors of the UPGRADING doc, rather than RFC Wiki
links like they have been in the past .

Re: [PHP-DEV] Official Twitter Account

[Trevor Suarez]

On Thu, Dec 6, 2018 at 11:08 AM Sara Golemon  wrote:

> On Thu, Dec 6, 2018 at 11:09 AM Trevor Suarez  wrote:
>
>> In any case, I feel like its usually the last place where I see
>> announcements made.
>
> I'll take exception to that.  I've been pushing both branches of the last
> several releases, and tweeting about it just after the announcements are
> visible on news.php.net.
> So no, if it's the last place you're seeing it, then you're only visiting
> fortune tellers.
>
>
>> For example, there's no tweet yet about the
>> announcement/availability of the PHP 7.3.0 release.
>>
>> Because I batch them, and the 7.0.33 announcement hasn't gone out yet.
> When that announcement happens, you'll see a tweet.
>
>
>> Its not a huge deal, really, but I follow a lot of PHP community members
>> that have all tweeted about 7.3.0 and I'd like to point people to the
>> official account for official announcements.
>>
>
> Because Europeans have different sleeping hours than Americans.
>
>
>> Maybe, in the future, tweeting from that account can be made a part of
>> coordinating an announcement? Just a thought. :)
>>
>> It is already.
>

Haha, all fair points.

What made me actually post this though, is that I saw you personally tweet
about it, Sara, along with a few others, and didn't see it on the official
account.

Sorry if I was way off base here. Keep up the good work. :)

[PHP-DEV] Official Twitter Account

[Trevor Suarez]

I'm not sure who runs the "official_php" Twitter account, but its supposed
to be THE account and is verified on Twitter (a relatively big deal as far
as account status goes on Twitter).

In any case, I feel like its usually the last place where I see
announcements made. For example, there's no tweet yet about the
announcement/availability of the PHP 7.3.0 release.

Its not a huge deal, really, but I follow a lot of PHP community members
that have all tweeted about 7.3.0 and I'd like to point people to the
official account for official announcements.

Maybe, in the future, tweeting from that account can be made a part of
coordinating an announcement? Just a thought. :)


- Trevor Suarez
https://trevorsuarez.com/

Re: [PHP-DEV] PHP allocating too much memory

[Trevor Suarez]

On Wed, Jun 15, 2016 at 11:34 AM, Michael Felt  wrote:

>
>
> On 15-Jun-16 15:55, Rowan Collins wrote:
>
>> On 15/06/2016 14:01, Peter LeBrun wrote:
>>
>>> The weirdest part about this is that PHP is somehow trying to allocate
>>> 140TB of memory.
>>>
>>
>> I've seen numbers like that a few times - always around 140TB, but the
>> exact number varies. I assume it's an overflow (or underflow?) somewhere,
>> but the exact mechanism escapes me. (It's close to 2^47, but not very
>> close; I've got examples logged as "low" as 140090229815192, and I think
>> I've seen under 140 trillion.)
>>
> In hex: 7F694C627798 - so apparently 7F694 is common to
> all.
> FYI: I have seen similar issues with mixed environments (32 and 64-bit) -
> at this point I am surprised that you can even dlopen() both sizes (my OS
> now refuses to dlopen() 32-bit modules aka shared libraries when 64-bit
> application and v.v.)
>
>> Apart from sheer curiosity of where this magic number comes from, I
>> wonder if there is some sanity check missing in the memory manager to at
>> least display a different error message...
>>
>> Regards,
>>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
I've seen this bug come up with the SOAP extension. I saw it happen when
instantiating a SoapClient or SoapServer when the constructor tries to load
a WSDL file under very certain circumstances. If the SOAP WSDL caching is
on (if `soap.wsdl_cache = 1`), the WSDL file is cached (or is attempting to
be cached) or the WSDL must be downloaded, and the file-system is full,
then this crazy overflow can happen. I believe it's due to the WSDL's
becoming corrupted due to the file-system halting the write of the file and
PHP not cleaning up the improper write.

In fact, this is a reported bug: https://bugs.php.net/bug.php?id=62337

Hope that helps! :)

- Trevor

Re: [PHP-DEV] [RFC] Add IntlTimeZone::getWindowsID() and IntlTimeZone::getIDForWindowsID() to ext/intl

[Trevor Suarez]

I just wanted to personally thank Sara Golemon, and the PHP internals team,
for being so incredibly approachable, open, and all-around awesome.

The fact that a simple, informal tweet can turn into a core feature is
incredible: https://twitter.com/trevorsuarez/status/709864419753377792

Thanks again!
- Trevor

>
>

Re: [PHP-DEV] Recap - Core functions throwing exceptions in PHP7

[Trevor Suarez]

Ah, I didn't realize this thread existed. I had just commented on the old
one, but the point still stands:

PHP 7.0 RC1 was just tagged.
Shouldn't this be a relatively high priority to fix/decide so we don't end
up with behavior that can't be fixed until PHP 8.0?

On Mon, Aug 10, 2015 at 6:54 PM Niklas Keller m...@kelunik.com wrote:

 
  Okay, great, we have people on both sides on this discussion. I hope
  nobody minds if I sit this part out.
 
  What specifics need to be discussed? Should somebody set up a poll? (I
  don't know how to do that.)


 You can find information on how to setup a poll in step 6 here:
 https://wiki.php.net/rfc/howto

 Regards, Niklas

Re: [PHP-DEV] Core functions throwing exceptions in PHP7

[Trevor Suarez]

PHP 7.0 RC1 was just tagged.
Shouldn't this be a relatively high priority to fix/decide so we don't end
up with behavior that can't be fixed until PHP 8.0?

On Sat, Aug 1, 2015 at 6:16 PM Scott Arciszewski sc...@paragonie.com
wrote:

 On Sat, Aug 1, 2015 at 6:37 AM, Nikita Popov nikita@gmail.com wrote:
  tl;dr: This should definitely throw, but I'm as yet unclear as to *what*
 it
  should throw. My gut says zpp should throw Error, length/min/max errors
  should throw Error and the randomness-not-available condition should
 throw
  Exception.

 Hi Nikita,

 This sounds reasonable to me. As I've said before, I don't have any
 real preference for which is thrown. If Aaron (author of the Throwable
 RFC that passed unanimously) wants to chime in, I'd almost certainly
 go with whatever you, him, and Anthony could agree on.

 Scott Arciszewski
 Chief Development Officer
 Paragon Initiative Enterprises https://paragonie.com

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

Re: [PHP-DEV] [RFC] Additional soft-reservations for PHP 7

[Trevor Suarez]

On Fri, Jul 3, 2015 at 12:24 PM Nikita Popov nikita@gmail.com wrote:

 Hi internals!

 In a previous thread on the topic [1] I promised to create an RFC for the
 soft-reservation of 'void', similar to a bunch of other reservations we
 have done for PHP 7. The RFC also includes 'enum' as an additional
 independent proposal, as I think this will likely be needed in 7.x. If you
 have further suggestions for names or keywords that we are likely to need,
 please point them out.

 https://wiki.php.net/rfc/additional_soft_reservations_for_php7

 Thanks,
 Nikita

 [1]: http://markmail.org/message/ovvnz5p2o6q7ebjl


Yea, this is smart to get this going. I think it makes a lot of sense. I'd
love to see struct added to this list, so we could potentially add a
value object structure of some sort down the road.

As far as prior art, you can see that there's already some interest in
this area:

- https://twitter.com/auroraeosrose/status/616321058904350720
- https://gist.github.com/auroraeosrose/2036d1d675a4bd254450
- https://gist.github.com/Antnee/237334e1eb937892ad7a

Anyway, yea. Makes sense to me. 

- Trevor

Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version

[Trevor Suarez]

Damn Gmail... I just top-posted. I'm going to go away for a while now...

On Wed, Apr 1, 2015 at 4:19 PM Trevor Suarez ric...@gmail.com wrote:

 Author of PR https://github.com/php/php-src/pull/1145 here.

 I'm really quite sorry. I didn't mean to create a mess here. I was just
 trying to contribute. :/

 Unfortunately, whether or not an RFC was necessary for an addition like
 this wasn't very clear. I'm an internals noob, so I simply tried to follow
 the flow of the addition of the similar method
 `DateTimeImmutable::createFromMutable()` that was added, without RFC
 (correct me if I'm wrong), in 5.6.0:
 http://php.net/manual/en/datetimeimmutable.createfrommutable.php

 Unfortunately, I'm not a huge fan of Derick's `createFromMutable()`
 method (why isn't there just a `createFromInstance()` or `copy()` method of
 some sort), but I tried to best follow the current design with my proposal
 and pull request.

 I think some clarification regarding what does or does-not require an RFC
 would make it much more helpful to contributors that want to help build PHP.

 Again, sorry if I caused any issue here.

 - Trevor

 On Wed, Apr 1, 2015 at 4:09 PM Dennis Birkholz den...@birkholz.biz
 wrote:

 Hi,

 Am 01.04.2015 um 21:43 schrieb Stanislav Malyshev:
  That is right and I think that is the reality we have to face: most
  users use distro versions. They get a new version when they need to
  upgrade their distro every few years.
 
  I'm not sure where you got this statistics from, but as I said, it is
  very easy to make .rpm or .deb with source version from php.net of the
  same minor. I've seen it done many times. It's next to impossible to
  make the same with different major, and nobody would do it for obvious
  stability concerns. I think the approach of you have to wait several
  years for any tiny change is terrible and detrimental for PHP
  development, however easy it makes the life of folks in Debian, etc.

 I vaguely remembered the usage statistics that Anthony assembled in
 December and had other numbers in my head. (see
 http://blog.ircmaxell.com/2014/12/php-install-statistics.html)

 5.5.12 (Ubuntu 14.10): 0.16%
 5.5.9 (Ubuntu 14.04): 1.81%
 5.4.16 (CentOS 7.0): 0.42%
 5.4.4 (Debian Wheezy): 2.14%
 5.3.10 (Ubuntu 12.04): 4.13%
 5.3.3 (Debian Squeeze, Centos 6.6): 10.37%
 5.3.2 (Ubuntu 10.04): 1.06%
 5.1.6 (CentOS 5.11): 1.14%
 ==
 Debian, Ubuntu and CentOS: ~21,23%

 (I assume here like Anthony that the installs matching a distribution
 specific version always come from that distribution).

 So I have to step a little back from my previous statement, only about
 1/5th of the installs seem to use distribution installs. But there are a
 lot of used versions in between. Why they don't upgrade I don't know,
 but if the upgrade would be a no-brainer without any risk for
 incompatibility, probably more would upgrade, but that is just
 speculation.

  No, I don't say ban non-security bugfixes. But I say don't add new
  methods/functionality that should go in the next feature release.
 
  I'm fine with adding only those that should go into the current one,
  namely small self-contained additions :) Just as we agreed on long ago.

 An addition and a bug fix are different things.

 Greets
 Dennis

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

Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version

[Trevor Suarez]

Author of PR https://github.com/php/php-src/pull/1145 here.

I'm really quite sorry. I didn't mean to create a mess here. I was just
trying to contribute. :/

Unfortunately, whether or not an RFC was necessary for an addition like
this wasn't very clear. I'm an internals noob, so I simply tried to follow
the flow of the addition of the similar method
`DateTimeImmutable::createFromMutable()` that was added, without RFC
(correct me if I'm wrong), in 5.6.0:
http://php.net/manual/en/datetimeimmutable.createfrommutable.php

Unfortunately, I'm not a huge fan of Derick's `createFromMutable()` method
(why isn't there just a `createFromInstance()` or `copy()` method of some
sort), but I tried to best follow the current design with my proposal and
pull request.

I think some clarification regarding what does or does-not require an RFC
would make it much more helpful to contributors that want to help build PHP.

Again, sorry if I caused any issue here.

- Trevor

On Wed, Apr 1, 2015 at 4:09 PM Dennis Birkholz den...@birkholz.biz wrote:

 Hi,

 Am 01.04.2015 um 21:43 schrieb Stanislav Malyshev:
  That is right and I think that is the reality we have to face: most
  users use distro versions. They get a new version when they need to
  upgrade their distro every few years.
 
  I'm not sure where you got this statistics from, but as I said, it is
  very easy to make .rpm or .deb with source version from php.net of the
  same minor. I've seen it done many times. It's next to impossible to
  make the same with different major, and nobody would do it for obvious
  stability concerns. I think the approach of you have to wait several
  years for any tiny change is terrible and detrimental for PHP
  development, however easy it makes the life of folks in Debian, etc.

 I vaguely remembered the usage statistics that Anthony assembled in
 December and had other numbers in my head. (see
 http://blog.ircmaxell.com/2014/12/php-install-statistics.html)

 5.5.12 (Ubuntu 14.10): 0.16%
 5.5.9 (Ubuntu 14.04): 1.81%
 5.4.16 (CentOS 7.0): 0.42%
 5.4.4 (Debian Wheezy): 2.14%
 5.3.10 (Ubuntu 12.04): 4.13%
 5.3.3 (Debian Squeeze, Centos 6.6): 10.37%
 5.3.2 (Ubuntu 10.04): 1.06%
 5.1.6 (CentOS 5.11): 1.14%
 ==
 Debian, Ubuntu and CentOS: ~21,23%

 (I assume here like Anthony that the installs matching a distribution
 specific version always come from that distribution).

 So I have to step a little back from my previous statement, only about
 1/5th of the installs seem to use distribution installs. But there are a
 lot of used versions in between. Why they don't upgrade I don't know,
 but if the upgrade would be a no-brainer without any risk for
 incompatibility, probably more would upgrade, but that is just speculation.

  No, I don't say ban non-security bugfixes. But I say don't add new
  methods/functionality that should go in the next feature release.
 
  I'm fine with adding only those that should go into the current one,
  namely small self-contained additions :) Just as we agreed on long ago.

 An addition and a bug fix are different things.

 Greets
 Dennis

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

Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5

[Trevor Suarez]

On Mon, Mar 16, 2015 at 5:04 PM Anthony Ferrara ircmax...@gmail.com wrote:

 All,

 Voting has been closed on the scalar type declarations v0.5 RFC:

 https://wiki.php.net/rfc/scalar_type_hints_v5

 At a final score of 108:48, it has been accepted for PHP 7.

 Thank you.

 Anthony

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


Wow, 156 votes.

As a non-internals developer that's been watching this RFC process for
quite some time, I'd just like to say thank you. Thank you to you Anthony,
and to Andrea, and to the entire collection of dedicated internals
developers and community members who worked so hard to make this possible.
This is a HUGE win for PHP. I can't wait to start using PHP 7. :)

Oh, and Congratulations!

- Trevor

Re: [PHP-DEV] Consistent function names

[Trevor Suarez]

... well that's a constructive way of going about it. I don't think Yasuo
did anything harmful or rude in making his proposal. Regardless of how
realistic the idea may be, I don't think its ever appropriate or
constructive to tell someone to simply stop because something is just
ridiculous.

On Wed, Mar 4, 2015 at 10:24 AM Rasmus Lerdorf ras...@lerdorf.com wrote:

 On 03/03/2015 07:34 PM, Yasuo Ohgaki wrote:
  Hi Michael,
 
  On Wed, Mar 4, 2015 at 12:15 PM, Michael Schuett 
 michaeljs1...@gmail.com
  wrote:
 
  Your evaluation is pretty anecdotal. I agree with some points but you
 need
  some solid evidence if you are going to rate these languages. Also do
 you
  have a list of all the functions you would like to rename or is this a
  sweeping lets just change everything so it matches and deprecate all the
  old stuff. Your matrix is a very weak push to do so. If you want to make
  these changes it would be better to choose a select set such as the
 array
  functions and try and push that through or see what that change might
 look
  like and if it's really beneficial to userland.
 
 
  I agree that my evaluation is subjective. For example, I rate PHP has 1
  security only
  because PHP is very weak against script/file inclusions because it's
 fatal
  and other
  languages apps do not have script/file inclusions as PHP apps do. Others
  might
  rate 2 or even 3 because it is too easy to fix it even if incident is
  fatal.
  (Security should be evaluated by how difficult to make mistakes, not
 how
  easy to
  fix mistakes generally. IMHO)
 
  I made list of rename candidates
  https://wiki.php.net/rfc/consistent_function_names#
 list_of_functions_to_be_renamed
  If you have suggestions, I appreciate!

 Yasuo, please stop. This isn't going to happen. Changing strlen() to
 str_len() is just ridiculous.

 -Rasmus

[PHP-DEV] [PR] DateTime::createFromImmutable() method

[Trevor Suarez]

Good morning internals!

I would like to propose a small addition be made to the DateTime class.

https://github.com/php/php-src/pull/1145

This is my first contribution to PHP's core, beyond documentation edits.
I'm not sure on the formalities that need to be taken for something like
this to be considered as an addition, or if an email like this is even
appropriate, so I'd absolutely welcome any guidance here.

I just saw a possible opportunity for an addition and thought it would be
fun to try and contribute to PHP. :)

I'm not a C programmer by any means, so please forgive me if I've made any
noob mistakes here, haha.

Thank you all for your time and consideration!


- Trevor

Re: [PHP-DEV] Follow-up to STH user experience, this time with actual testing

[Trevor Suarez]

Thank you so much for taking the time to do this. Your explanations of a
more real-world example are extremely valuable and provide a very strong
hint at the effects that these RFC implementations may have, both in the
short and long term.

Seriously, very appreciated.

On Thu, Feb 26, 2015 at 7:30 PM Matthew Weier O'Phinney matt...@zend.com
wrote:

 I've taken some time the last couple days to compile both the Scalare Type
 Hints
 v0.5 (heretofor STHv5) and Coercive Scalar Type Hints (heretofore
 STHcoerce)
 patches and test some code against them.

 In each case, I modified the `Phly\Http\Response` class from my phly/http
 package to add scalar type hints, remove previous argument validation, and
 then
 ran the unit tests. Here's my details of the experience, and analysis.

 ### STHv5

 With STHv5, my tests failed out of the box. First, I needed to add an error
 handler that would convert the E_RECOVERABLE_ERROR to an
 InvalidArgumentException so that I would get useful error messages from
 PHPUnit.
 Next, once I had done that, I had tests that were throwing invalid input at
 methods, and validating that the invalid arguments were caught. This
 worked in
 all but one specific case: passing a float value to an argument expecting
 an
 integer. In this particular case, the value was coerced to an integer,
 albeit
 lossily, and no error was raised.

 When I changed my test case to operate under strict_types mode, the test
 executed as I had originally expected, and succeeded.

  Analysis

 I did not expect the float value to be coerced, particularly as it had a
 fractional part. Yes, I understand that this is how casting _currently_
 works in
 PHP, and that the patch uses the current casting rules. However, I'd
 expect that
 any float with a fractional value would not be cast to an integer; doing
 so is
 lossy, and can lead to unexpected results.

 The strict_types mode operated how I would expect it, but meant I was
 forced to
 add the declaration to the top of the file. Which leads to this:

 My tests operated differently in strict vs normal mode. That means my code
 does,
 too. Testing both modes would be difficult to do in an automated fashion;
 essentially, you're left needing to choose to support one mode or the
 other.
 This goes back to the point I was making earlier this week: I worry that
 having
 two modes will lead to a schism in userland libraries: those that support
 strict, and those that do not; there will be little possibility of testing
 both.

 ### STHcoerce

 With STHcoerce, my tests also failed out of the box, but not for the same
 reason. Instead, I had a bunch of errors reported based on code that
 PHPUnit was
 executing! In this case, I discovered that:

 - PHPUnit passes a boolean false to `debug_backtrace()`... which is
 documented
   as expecting an integer! (There are actually several constant values it
   accepts, all of which are integer values.) In this case, PHPUnit is
 relying
   on the fact that the engine casts booleans to the integers 0 and 1.
 (Zeev has
   written to the list already indicating that this coercion path will be
   supported in the patch.)
 - PHPUnit is passing the results of $reflector-getDocComment() blindly to
   substr() and preg_match*(). getDocComment() is documented as returning
 EITHER
   a string OR boolean false. Again, PHPUnit is relying on PHP to cast
 boolean
   false to an empty string. (Zeev has also indicated this coercion path
 may be
   re-introduced.)

 I was able to fix these in a matter of minutes, and then my tests ran, and
 passed without any changes.

  Analysis

 STHcoerce worked about how I expect STHv5 will work _if_ _every_ _file_
 were
 declared in strict_types mode. In other words, it uncovered errors in
 calling
 both userland and internal functions. Userland typehints worked as I
 expected,
 with floats using fractional values not casting to integers.

 ### Wrap Up

 STHcoerce was actually far more strict than I found strict_types mode to
 be in
 STHv5. The reason is that it's a single, non-optional mode. This poses a
 potential challenge to migration, as noted in my problems using PHPUnit
 (Yes, I
 WILL be sending patches their way soon!): method calls and arguments that
 previously worked because of how PHP juggles types often do not work,
 particularly when going from boolean to other scalar values. However, the
 patch
 does what I'd expect in terms of preventing operations that would result in
 either data loss or data additions, all of which can have unexpected side
 effects if you don't understand the casting rules currently.

 The flip side to this is that you do not need to make any changes to your
 code
 in order to locate and fix errors. What this means from a library/framework
 author perspective is that, if the STHcoerce patch is merged, I can test
 against
 PHP 7, make fixes, and my code is not only forward-compatible, but also
 backwards to the various PHP 5 versions I might already be supporting —
 and 

[PHP-DEV] Quick RFC Wiki change

[Trevor Suarez]

Hi internals,

I was just browsing the RFC wiki page when I noticed a sub-section for PHP
5.7 under the Implemented section[1]. Considering that the PHP 5.7 version
RFC was put to a vote and failed[2], I'm wondering why these items are
still in this section.

Should we move these 5.7 items to the 7.0 section?

Thanks!
- Trevor


[1]: https://wiki.php.net/rfc#php_57
[2]: https://wiki.php.net/rfc/php57#vote

Re: [PHP-DEV] Re: [RFC] Exceptions in the engine

[Trevor Suarez]

I think that structure makes sense Dmitry.

Though, just a bit on naming here (I know, its not a big deal, and naming
is hard, haha):

I think that naming the new parent exception something like Throwable or
Catchable (as Nikita previously suggested) would be a bit more concise in
meaning than BaseException. You may not have even meant that name as a
formal proposal, but I figured I'd weigh in regardless. :P

- Trevor

On Thu Feb 19 2015 at 4:55:38 AM Dmitry Stogov dmi...@zend.com wrote:

 On Wed, Feb 18, 2015 at 10:30 PM, Dan Ackroyd dan...@basereality.com
 wrote:

  On 13 February 2015 at 23:25, Nikita Popov nikita@gmail.com wrote:
   Subclassing: Should there be more specific subclasses of
 EngineException
   for particular errors?
 
  It's not obvious that any subclasses would be useful. However using
  the code to specify the exact type of error, rather than having to
  inspect the message would be good.
 
   Should EngineException inherit from Exception (and as such be
   subject to catch(Exception)) or should we introduce some kind
   of special super-class that is not caught by default
 
  Even ignoring the BC problem with having EngineExceptions extending
  Exception, I think the EngineException needs to be in a different
  hierarchy to Exception to be able to write reasonable code in the
  future
 
  Without having EngineException in a separate hierarchy of exceptions,
  the code below will catch exceptions where the data is 'ok' but there
  was a problem with the code, and continue to process items. This is
  almost certainly not the correct behaviour when an EngineException has
  been encountered.
 
  interface Service {
  function foo($item);
  }
 
 
  function processData(array $itemsToProcess, service $service) {
  foreach ($itemsToProcess as $item) {
  try {
  $service-foo($item);
  }
  // Because $service can throw an Exception that is specific to the
  // implementation we have to catch \Exception, unless we are going
  // to list all possible implementation specific exception types here.
  // That would be a subtle case of strong coupling, and when a new
  // implementation is made the new exception type would need to
  // be added here.
  catch(\Exception $e) {
  // item was not processable but PHP engine is OK.
  $item-markAsErrored();
  //Go on to process the next item
  }
  }
  }
 
 
  To avoid having EngineExceptions in a separate hierarchy, this
  function could be converted to:
 
  function processData(array $itemsToProcess, service $service) {
  foreach ($itemsToProcess as $item) {
  try {
  $service-foo($item);
  }
  catch(\EngineException $ee) {
  //PHP engine is not stable - lets get out of here.
  throw $ee; //or throw new ProcessException($ee)
  }
  catch(\Exception $e) {
  $item-markAsErrored();
  }
  }
  }
 
  However that is bad as i)it's boiler plate to do the correct behaviour
  ii) you have to remember to do that everywhere. Having to remember to
  do the correct thing, is going to lead to people forgetting.
 
  It will still be necessary to catch all types of Exception in a single
  catch block i.e. at the top level of a script to prevent exceptions
  being shown to the end user. This could be made easier by having a
  common super class for Exception and EngineException. However having
  one try block that is required to have multiple catch statements to
  catch all different types of exception is not that much of a burden:
 
  try {
  runApp();
  }
  catch(EngineException $e) {
  handleException($ee);
  }
  catch(Exception $e) {
  handleException($e);
  }
 
  As that would be the only place it would be required to catch both types.
 
  TL:DR EngineException needs to not extend Exception, whether we need a
  super class is not as clear.
 
  cheers
  Dan
 
  --
  PHP Internals - PHP Runtime Development Mailing List
  To unsubscribe, visit: http://www.php.net/unsub.php
 
 
 I think we may introduce the following hierarchy

 abstarct class BaseException {
 }
 class Exception extends BaseException {
 }
 class EngineException extends BaseException {
 }

 the existing code that caught Exception is going to be unaffected.
 New code may decide to catch engine exception in separate catch block
 (using EngineException) or in single block (using BaseException)

 Thanks. Dmitry.

[PHP-DEV] [PR] DateTime RFC7231 constant

[Trevor Suarez]

Good early morning (late night for me) internals!

I would like to propose a small addition be made to the DateTime date
format constant definitions.

https://github.com/php/php-src/pull/882

This is my first contribution to PHP's core. I wasn't sure if something of
this nature would require an RFC, but I tried to register for a Wiki
account and was met with page errors anyway (if anyone could point me in
the right direction to notify someone of the wiki registration page failing
https://wiki.php.net/rfc?do=register, that'd be awesome).

Since I was unable to create an RFC anyway, I attempted to make the pull
request description as close to the RFC template/format as I could. I'm
sorry if I'm missing anything there. Please let me know if I am.

My C skills are near non-existent, but luckily this PR requires very little
C code. :P

Thank you all for your time!

- Trevor

Re: [PHP-DEV] Currently supported versions of PHP

[Trevor Suarez]

Great job on this Adam. You whipped this up pretty quickly and it looks
good!

On Mon Oct 27 2014 at 5:21:30 PM Adam Harvey ahar...@php.net wrote:

 On 27 October 2014 18:29, Sebastian Bergmann sebast...@php.net wrote:
  On 10/27/2014 10:45 AM, Peter Cowburn wrote:
  The closest we have, at the moment, is probably http://php.net/eol.php
  which details the versions which are no longer supported.
 
   We need the inverse of that :)
 
  Good question.
 
   Should we start http://php.net/supported-versions.php then?

 I did most of the work to support this a few weeks back, as the bug
 tracker needed to be able to pull the currently supported versions
 from somewhere when qa.php.net is down, so this is mostly just a case
 of wiring up the data into something readable.

 It hasn't propagated to all the mirrors yet, but we now have
 http://us2.php.net/supported-versions.php, as suggested. I used the
 Wikipedia table for inspiration (that is, I blatantly stole the
 formatting), and also added a basic SVG calendar which people seem to
 like when I show it in conference talks.

 Thoughts? (I haven't linked it from anywhere yet, so it's not really
 live as such.)

 Adam

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

Re: [PHP-DEV] Re: [VOTE] Abstract Syntax Tree

[Trevor Suarez]

 If we're talking the plunge of putting exceptions into the core engine,
 wouldn't it make sense to convert most of the fatal errors (especially
 the catchable ones) to exceptions too? Most of them (except for out of
 memory, timeouts and such) don't really require the engine to shut down,
 as it seems... So if we're already saying people will have to deal with
 exceptions in PHP engine anyway, maybe we could make it so that we could
 have unified handling of them?


This is something that Nikita had originally proposed in an RFC (
https://wiki.php.net/rfc/engine_exceptions) but postponed until after 5.6.

I have a feeling we'll be hearing about its resurrection soon enough.

- Trevor

Re: [PHP-DEV] On BC and not being evil (Was: Re: [PHP-DEV] [RFC] Integer Semantics)

[Trevor Suarez]

What if we were to *quantify* backwards compatibility in a way, as opposed
to just discussing the hypothetical BC breaking potential of a change?

I've never thought of this before, but this discussion had me thinking...
When I write a library that has a large user base, I try to write as many
unit tests and potential regression tests as possible. Unfortunately, the
larger the user base and the larger the feature set, the more coverage is
necessary. A language like PHP, it would be nearly unlimited. But stay with
me here. What's better than a simple unit of testing or benchmarking? Most
of us know that not much really beats real world application testing, or at
least a more realistic form of feature use.

This is where the Hack team got it right. Hack, during its early
development (and even still) used a suite of PHP frameworks, libraries, and
well known projects to test their PHP compatibility. Ironically, I believe
that Hack originally used these types of test due to a lack of a language
specification: there was no other way to really make sure to match the
language's behavior. However I think that this type of testing is valuable
anyway. What if we were to create a (or borrow Hack's) framework testing
suite and run PHP 7 and upcoming RFC patches against the suite before
accepting them.

Yes, likely things will fail with BC breaks, but then the PHP internals
team (or the RFC writer, hopefully) could then see exactly what was being
used in a given framework that might break. Even better, the internals/RFC
developer could see how much effort would be required to fix the BC break
in the broken tested framework and could gauge whether the break was
worthwhile or not a lot more. Finally, even more importantly, we could see
the range of libraries and frameworks that would break with a given change
and even introduce a potential RFC rule for BC breaking (on major versions,
etc)... like we have with rules around certain voting majorities based on
the type of language change, we could have a certain percentage of
libs/frameworks that would have to be compatible (or somehow quantify the
effort needed to update each [can it be automated via a tool or not]).

Anyway, just spit balling here. I know it would take effort, but this could
make a huge difference in our oops moments and quality checking for the
language updates. Hell, maybe it would even make us more apt to
greenlight features that we'd otherwise be afraid of because we'd see
that it wouldn't be as big of a deal as we thought.

Overall I think this would reduce a lot of the conjecture and
discussion/fear around possible BC breaks that could help or hurt the
project and the future of the language.

*Trevor Suarez*
+Trevor Suarez https://plus.google.com/+TrevorSuarez
@trevorsuarez https://twitter.com/trevorsuarez


On Thu, Aug 21, 2014 at 2:17 PM, Stas Malyshev smalys...@sugarcrm.com
wrote:

 Hi!

  And since you're targetting the next major release, BC isn't an issue.
 
  This sort of blanket statements that Backwards Compatibility is not an
  issue with a new major version is extremely unwarranted. *Extreme care*
  should be taken when deciding to break Backwards Compatibility. It
  should not be oh we have a major new version so we can break all the
  things™.

 I agree. Major means we *can* break BC, if there's a reason good enough,
 but that doesn't mean we get to break BC *for free*. We do need to
 carefully weight it each time and ensure it is worth it, not dismiss it
 with oh, it's PHP 7, so we can do anything we want, BC is no longer a
 concern. We have millions of people using PHP 5, and the goal is for
 almost all of them to eventually use PHP 7, otherwise there's no point
 in it. Each BC break creates another hurdle on the way to it. We should
 take it seriously.
 --
 Stanislav Malyshev, Software Architect
 SugarCRM: http://www.sugarcrm.com/

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