Re: [PHP-DEV] [RFC:generics]

I agree. On Wed, Apr 20, 2016 at 2:01 PM, Sara Golemon wrote: > On Tue, Apr 19, 2016 at 7:56 PM, Jesse Schalken > wrote: > >> class Collection {... > > > > I think the "where T is Traversable, T is Countable" syntax was intended > to > > represent the

Re: [PHP-DEV] [RFC:generics]

On Tue, Apr 19, 2016 at 7:56 PM, Jesse Schalken wrote: >> class Collection {... > > I think the "where T is Traversable, T is Countable" syntax was intended to > represent the intersection (i.e. a "Countable Traversable"), not the union. > > So you would need an

Re: [PHP-DEV] [RFC:generics]

On Tue, Apr 19, 2016 at 7:54 PM, guilhermebla...@gmail.com wrote: > 1- Even though mentioned, I'd still use "extends" or "implements" instead of > "is" (which would be a new pseudo-reserved keyword) to enforce data type > consistency and prevent developers to

Re: [PHP-DEV] RFC: Anonymous Class Lexical Scope

I'm not sure it matters, but there is some precedent for this in JavaScript/ES6: function foo(bar) { return new class { myBar = bar; getBar() { return this.myBar; } }(); } console.log(foo('hello').getBar()); // "hello" (You can actually reference

Re: [PHP-DEV] [RFC:generics]

On Wed, Apr 20, 2016 at 8:22 AM, Sara Golemon wrote: > On Tue, Apr 19, 2016 at 1:16 PM, Mathieu Rochette > wrote: > > about the upper bounds, have you consider another way of describing the > > constraints, eg: > > > > class Box where T is Boxable > > > >

Re: [PHP-DEV] [RFC:generics]

Hi, Here are a couple of comments towards Generics support to PHP. 1- Even though mentioned, I'd still use "extends" or "implements" instead of "is" (which would be a new pseudo-reserved keyword) to enforce data type consistency and prevent developers to potentially referring to one thing while

Re: [PHP-DEV] [RFC:generics]

On Tue, Apr 19, 2016 at 4:13 PM, Stanislav Malyshev wrote: >> class Collection {... > > I am sorry if this sounds harsh, but I really hope we won't have > something like this in PHP. Java templates are complex and weird enough, > adding another layer on top of that to allow

Re: [PHP-DEV] Re: Improving PHP's type system

On Tue, 2016-04-19 at 17:21 -0600, Rick Widmer wrote: > > Are too many of these incompatible shiny things, too fast, the main > reason so many PHP users are on older versions? There are many reasons. Often the reason is simply that many cheap hosting companies or admins don't want to spend time

Re: [PHP-DEV] Re: Improving PHP's type system

Hi! > So the Symfony2 routing and Doctrine ORM are academic proof of concepts? I'm sorry I'm a bit lost about how you got from "prioritizing 'interesting playground' is more suited for academic PoC than for a mature language" to "Doctrine ORM is an academic PoC". I have little knowledge on what

Re: [PHP-DEV] Re: Improving PHP's type system

On Wed, 2016-04-20 at 00:09 +0200, Marco Pivetta wrote: > In Doctrine ORM, having a way to know that a field or parameter is a > `string | null` or a `int | float` may be the difference between > knowing > what kind of column definition is needed for a field at DB level, > without > even need for

Re: [PHP-DEV] Re: Improving PHP's type system

Hi! > Are too many of these incompatible shiny things, too fast, the main > reason so many PHP users are on older versions? Probably not directly. The reason is PHP 5, as is, is pretty darn good tool for what it is being used for. Of course, it could be 10x faster, it could have more extensions

Re: [PHP-DEV] Re: Improving PHP's type system

On 4/19/2016 5:10 PM, Stanislav Malyshev wrote: In general, improving the type system provides a much more interesting and practical playground for any kind of tool that would rely on static That's my point - "more interesting playground" does not sound like a reason enough to mess with the

Re: [PHP-DEV] Re: Improving PHP's type system

On 20 April 2016 at 01:12, Ronald Chmara wrote: > On Tue, Apr 19, 2016 at 3:09 PM, Marco Pivetta wrote: > > In general, improving the type system provides a much more interesting > and > > practical playground for any kind of tool that would rely on static

Re: [PHP-DEV] [RFC:generics]

Hi! > class Collection {... I am sorry if this sounds harsh, but I really hope we won't have something like this in PHP. Java templates are complex and weird enough, adding another layer on top of that to allow type expressions IMHO is really taking it too far. -- Stas Malyshev

Re: [PHP-DEV] Re: Improving PHP's type system

On Tue, Apr 19, 2016 at 3:09 PM, Marco Pivetta wrote: > In general, improving the type system provides a much more interesting and > practical playground for any kind of tool that would rely on static > introspection: IDEs, reflectors, code generators, code inliners, So,

Re: [PHP-DEV] Re: Improving PHP's type system

Hi! > Any reflector-based system, such as a serializer, an ORM or just a > dependency injection or configuration loader would be able to do operations > in a much more precise and less complex way. This should be solved by annotations. Yes, I know all the story, but it does not change the fact

Re: [PHP-DEV] Re: Improving PHP's type system

On 4/19/2016 2:41 PM, Stanislav Malyshev wrote: I try to share my worry that some of the things being proposed include seriously complicating PHP's conceptual model while serving at best infrequent use cases. Simplicity is a virtue, and we have already lost significant amount of that virtue.

Re: [PHP-DEV] Re: Improving PHP's type system

On 20 April 2016 at 00:30, Zeev Suraski wrote: > > this is not a make or break feature for PHP. > That's why it's called a "feature" Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/

Re: [PHP-DEV] Re: Improving PHP's type system

On 20 ? 2016, at 1:10, Marco Pivetta > wrote: On 19 April 2016 at 23:47, Zeev Suraski > wrote: I fail to see how adding C++ templates to PHP takes it to the next level in anything but the complexity scale.

Re: [PHP-DEV] [RFC:generics]

On Tue, Apr 19, 2016 at 1:16 PM, Mathieu Rochette wrote: > about the upper bounds, have you consider another way of describing the > constraints, eg: > > class Box where T is Boxable > > this would allow multiple constraints, eg: > > class Collection where T is Traversable,

Re: [PHP-DEV] Re: Improving PHP's type system

On 19 April 2016 at 23:47, Zeev Suraski wrote: > I fail to see how adding C++ templates to PHP takes it to the next level > in anything but the complexity scale. Not having them is not preventing > anybody from doing anything today. Sure, a bunch of frameworks would adopt > them

RE: [PHP-DEV] Re: Improving PHP's type system

> -Original Message- > From: morrison.l...@gmail.com [mailto:morrison.l...@gmail.com] On Behalf > Of Levi Morrison > Sent: Wednesday, April 20, 2016 12:23 AM > To: Zeev Suraski > Cc: Larry Garfield ; internals@lists.php.net > Subject: Re: [PHP-DEV]

Re: [PHP-DEV] Re: Improving PHP's type system

> IMHO, it would be AWESOME if we could funnel some of these cycles from new > syntax and onto other things like parallel processing, async IO, JIT and more > - which can truly take PHP to the next level. New syntax cannot. The time investment for those projects is enormous. Not many

RE: [PHP-DEV] Re: Improving PHP's type system

> -Original Message- > From: Larry Garfield [mailto:la...@garfieldtech.com] > Sent: Tuesday, April 19, 2016 11:07 PM > To: internals@lists.php.net > Subject: Re: [PHP-DEV] Re: Improving PHP's type system > > strawman? A number of people are using it, and it's a flippant and insulting >

Re: [PHP-DEV] [VOTE] Catching Multiple Exception Types

>> Except these two are in separate libraries that cannot share an interface. > > If these are separate libraries, you can't be sure that method does the > same thing, or even that it will be existing in both. This is not true. I can read the documentation for each method and know they are the

Re: [PHP-DEV] Re: Typed properties patch

Hi! > OK. In my opinion, if something is defined as "int" should be always > "int". Nor "null" neither "undefined". > This is good for programmers who think like me, for compiler and for > hardware CPU :) I understand why it's good, and I agree. The harder question is whether we can deliver on

Re: [PHP-DEV] Re: Improving PHP's type system

Hi! > same thing as "PHP is not $other_language, therefore nothing from that > language is useful for PHP." Which is an utterly wrong and useless No, it's not. Nobody claims *nothing* from other languages is useful in PHP. What is claimed instead that *not everything* from other languages is

Re: [PHP-DEV] [RFC:generics]

On 04/19/2016 06:28 PM, Dominic Grostate wrote: > We would really like some feedback on this. We know it is a massive > feature, but we have put in quite a lot of research in both the language > implications and implementation challenges. Please ask any questions you > have. thank you all for

Re: [PHP-DEV] Re: Typed properties patch

On 04/19/2016 10:53 PM, Stanislav Malyshev wrote: Hi! More properly - PHP is done in a way that doesn't allow big data processing yet :) LuaJIT may be used for in-kernel packet filtering... But we're not targeting PHP for in-kernel packet filtering. And we should not sacrifice language

RE: [PHP-DEV] Re: Improving PHP's type system

> -Original Message- > From: Fleshgrinder [mailto:p...@fleshgrinder.com] > Sent: Tuesday, April 19, 2016 11:03 PM > To: Zeev Suraski > Cc: internals@lists.php.net > Subject: Re: [PHP-DEV] Re: Improving PHP's type system > > On 4/19/2016 8:48 PM, Zeev Suraski wrote: > >>

Re: [PHP-DEV] [VOTE] Catching Multiple Exception Types

On 4/19/2016 9:39 PM, Stanislav Malyshev wrote: > Hi! > >> Except these two are in separate libraries that cannot share an interface. > > If these are separate libraries, you can't be sure that method does the > same thing, or even that it will be existing in both. > >> An interface is not

Re: [PHP-DEV] Re: Improving PHP's type system

On 4/19/16 1:43 PM, Stanislav Malyshev wrote: Hi! Creating a generic feature that makes sense in a handful of situations, while at the same time being one that's waiting-to-be-abused in the vast majority of the rest (or as Tom put it, a 'footgun') is a pretty poor bargain IMHO. Completely

Re: [PHP-DEV] Re: Improving PHP's type system

On 4/19/2016 8:48 PM, Zeev Suraski wrote: >> but it does not help with primitive types. :( > > Which is fine. Primitive types can and should get dedicated solutions. > There's really no need for allowing over creativity with userland-customized > scalar types. > Hmmm... nope. I already

Re: [PHP-DEV] Re: Typed properties patch

Hi! > More properly - PHP is done in a way that doesn't allow big data > processing yet :) > > LuaJIT may be used for in-kernel packet filtering... But we're not targeting PHP for in-kernel packet filtering. And we should not sacrifice language semantics for minuscule gains in performance.

Re: [PHP-DEV] [VOTE] Catching Multiple Exception Types

Hi! > Except these two are in separate libraries that cannot share an interface. If these are separate libraries, you can't be sure that method does the same thing, or even that it will be existing in both. > An interface is not possible: separate libraries. Duck-typing is not > appropriate:

Re: [PHP-DEV] [VOTE] Catching Multiple Exception Types

On Tue, Apr 19, 2016 at 2:13 PM, Stanislav Malyshev wrote: > Hi! > > > namespace Application; > > function log(Eloquent\Collection | Haldayne\Map $entity) { > > $logger->log($entity->toArray()); > > } > > This is bad design. It assumes that two completely unrelated

RE: [PHP-DEV] Re: Improving PHP's type system

> -Original Message- > From: Fleshgrinder [mailto:p...@fleshgrinder.com] > Sent: Tuesday, April 19, 2016 8:33 PM > To: Zeev Suraski ; Larry Garfield > > Cc: internals@lists.php.net > Subject: Re: [PHP-DEV] Re: Improving PHP's type system > > On

Re: [PHP-DEV] Re: Improving PHP's type system

Hi! > Creating a generic feature that makes sense in a handful of > situations, while at the same time being one that's > waiting-to-be-abused in the vast majority of the rest (or as Tom put > it, a 'footgun') is a pretty poor bargain IMHO. Completely agree with Zeev here. It also seems to me

Re: [PHP-DEV] Proposal: Startup snapshot for optimizing app load time

It should be possible to do this for functions and simple classes. Most probably this will require some engine changes, but this is not a big problem for major release. Conditional definition and run-time class inheritance will make significant troubles. Thanks. Dmitry.

Re: [PHP-DEV] Proposal: Startup snapshot for optimizing app load time

On Tue, 2016-04-19 at 23:59 +0800, Lin Yo-An wrote: > > Yes! not all global variables will be snapshotted, for now I think > EG, SPL_G (which saves the autoloader instances), and some object > instances and zval. Then these opcode could be skipped a lot. So this > looks like something on top of

Re: [PHP-DEV] [VOTE] Catching Multiple Exception Types

Hi! > namespace Application; > function log(Eloquent\Collection | Haldayne\Map $entity) { > $logger->log($entity->toArray()); > } This is bad design. It assumes that two completely unrelated classes have the same function and it means the same. If it's indeed true, we have a way to express

Re: [PHP-DEV] Proposal: Startup snapshot for optimizing app load time

On 4/19/2016 6:54 PM, David Zuelke wrote: > I think this solution is merely a band-aid for a more profound architectural > weakness of current PHP setups, where a web server call out to the engine > (via embedding or FastCGI) to execute a script, which causes this recurring > initialization

Re: [PHP-DEV] Re: Improving PHP's type system

On 4/19/2016 4:36 AM, Tom Worster wrote: > On 4/18/16 4:34 AM, Tony Marston wrote: > >> I repeat, where was the insult in the post in question? What exactly >> were the insulting words? > > I chose just one example: > >> Those who cannot write effective software without these "clever" >>

Re: [PHP-DEV] Re: Improving PHP's type system

On 4/19/2016 11:41 AM, Zeev Suraski wrote: > It could actually implement all of them - the two parents, and the child. > That sounds like a pretty good, explicit way that requires no introduction of > any new syntax, concepts or engine complexity in order to do what you're > describing. This

Re: [PHP-DEV] [RFC] Nullable Return Type Declaration

On 4/19/2016 12:02 AM, Lester Caine wrote: > On 18/04/16 20:08, Fleshgrinder wrote: >> This is however a useful shortcut and shortcuts are good things in >> terms of usability if done write. Think of + vs. right click copy (or any other example of useful keyboard shortcuts). > > Except

Re: [PHP-DEV] Proposal: Startup snapshot for optimizing app load time

I think this solution is merely a band-aid for a more profound architectural weakness of current PHP setups, where a web server call out to the engine (via embedding or FastCGI) to execute a script, which causes this recurring initialization overhead in the first place. The future is (or

Re: [PHP-DEV] [RFC:generics]

We would really like some feedback on this. We know it is a massive feature, but we have put in quite a lot of research in both the language implications and implementation challenges. Please ask any questions you have. Thanks. On 18 Apr 2016 11:24 a.m., "Josh Di Fabio"

Re: [PHP-DEV] RFC: Anonymous Class Lexical Scope

Hi Nikita, I was thinking some more about your suggestion: Nikita Popov wrote on 19/04/2016 15:18: $foo = 42; return new class { private $bar = $foo; public function getBar() { return $this->bar; } } If we allowed this, would it make sense to also allow it in named classes? This

Re: [PHP-DEV] RFC: Functional Interfaces

Larry Garfield wrote on 19/04/2016 16:21: Which is why I'm not sure I like that approach, because the place I then call $handler needs to have a conditional in it. There's another RFC that was posted to Twitter but hasn't made it to the list yet that seems to solve this better:

Re: [PHP-DEV] RFC: Functional Interfaces

Hi! 2016-04-19 11:21 GMT-04:00 Larry Garfield : > On 4/19/16 10:02 AM, Rowan Collins wrote: > >> Dmitry Stogov wrote on 19/04/2016 15:48: >> >>> callable-type is much simpler solution for this use-case. >>> Usage of Interfaces to check function prototypes is a bit tricky,

Re: [PHP-DEV] RFC: Functional Interfaces

On 4/19/16 10:02 AM, Rowan Collins wrote: Dmitry Stogov wrote on 19/04/2016 15:48: callable-type is much simpler solution for this use-case. Usage of Interfaces to check function prototypes is a bit tricky, but yes, this is a possible use-case. Do you like to work with framework, that use this

Re: [PHP-DEV] RFC: Functional Interfaces

Dmitry Stogov wrote on 19/04/2016 15:48: callable-type is much simpler solution for this use-case. Usage of Interfaces to check function prototypes is a bit tricky, but yes, this is a possible use-case. Do you like to work with framework, that use this trick for every callback? If you don't

Re: [PHP-DEV] RFC: Functional Interfaces

On 04/19/2016 05:30 PM, Rowan Collins wrote: Dmitry Stogov wrote on 19/04/2016 15:12: I prefer intuitive concepts, that I may use without rereading manual again and again. For this one, I even can't imagine a natural (not over-designed) use case. The use case that came to my mind is kind

Re: [PHP-DEV] RFC: Anonymous Class Lexical Scope

Nikita Popov wrote on 19/04/2016 15:18: I'd like to suggest an alternative syntax: $foo = 42; return new class { private $bar = $foo; public function getBar() { return $this->bar; } } That is, allow properties inside the anonymous class to be initialized based on values from the

Re: [PHP-DEV] RFC: Anonymous Class Lexical Scope

On 04/19/2016 05:18 PM, Nikita Popov wrote: On Tue, Apr 19, 2016 at 3:31 PM, Joe Watkins wrote: Morning Internals, Please review the following RFC: https://wiki.php.net/rfc/lexical-anon A look at the patch from those of you that do that would be good

Re: [PHP-DEV] RFC: Functional Interfaces

Dmitry Stogov wrote on 19/04/2016 15:12: I prefer intuitive concepts, that I may use without rereading manual again and again. For this one, I even can't imagine a natural (not over-designed) use case. The use case that came to my mind is kind of the other way around from "syntax sugar for

Re: [PHP-DEV] RFC: Anonymous Class Lexical Scope

On 19/04/16 16:18, Nikita Popov wrote: On Tue, Apr 19, 2016 at 3:31 PM, Joe Watkins wrote: Morning Internals, Please review the following RFC: https://wiki.php.net/rfc/lexical-anon A look at the patch from those of you that do that would be good :)

Re: [PHP-DEV] RFC: Anonymous Class Lexical Scope

On Tue, Apr 19, 2016 at 3:31 PM, Joe Watkins wrote: > Morning Internals, > > Please review the following RFC: > > https://wiki.php.net/rfc/lexical-anon > > A look at the patch from those of you that do that would be good :) > Hey Joe, The syntax and semantics

Re: [PHP-DEV] RFC: Functional Interfaces

For me, the proposal is too complex. I prefer intuitive concepts, that I may use without rereading manual again and again. For this one, I even can't imagine a natural (not over-designed) use case. But this is my personal opinion, and I may be wrong :) I'll review the code later. Thanks.

[PHP-DEV] NEUTRAL Benchmark Results for PHP Master 2016-04-19

Results for project PHP master, build date 2016-04-19 06:35:05+03:00 commit: 60b1441 previous commit:a186ac0 revision date: 2016-04-07 10:26:32+09:00 environment:Haswell-EP cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping 2, LLC 45 MB

[PHP-DEV] RFC: Anonymous Class Lexical Scope

Morning Internals, Please review the following RFC: https://wiki.php.net/rfc/lexical-anon A look at the patch from those of you that do that would be good :) Cheers Joe

Re: [PHP-DEV] RFC: Functional Interfaces

On 04/19/2016 03:52 PM, Joe Watkins wrote: Oh, it's confusing text in the RFC, using the word "Interface" ... that's meant as a placeholder for InterfaceName. Cheers Joe On Tue, Apr 19, 2016 at 1:50 PM, Joe Watkins > wrote: Morning

Re: [PHP-DEV] RFC: Functional Interfaces

> What value? Yes, shorter, more concise (from the programmers perspective) syntax. Right now, if you do a lot of work with Closures, you have to verify their interface, the value in having the engine do it for you seems really obvious. But also ... > I thought the same might be implemented

Re: [PHP-DEV] [VOTE] Catching Multiple Exception Types

On 04/19/2016 04:09 PM, Levi Morrison wrote: On Tue, Apr 19, 2016 at 6:39 AM, Dmitry Stogov wrote: Only one note. I would prefer to use "," instead of "|" as a class name separator. Especially if "Union types" are not accepted. The rest should be fine. On the other hand if

Re: [PHP-DEV] [VOTE] Catching Multiple Exception Types

On Mon, Apr 18, 2016 at 9:28 PM, Stanislav Malyshev wrote: > Hi! > > > It's about the perception of consistency. "Oh, I can do this! Neat:" > > > > function neat(Foo | Bar $a) { ... } > > You shouldn't be able to do this, because it makes no sense - why would > a function

Re: [PHP-DEV] [VOTE] Catching Multiple Exception Types

> On 19 באפר׳ 2016, at 15:46, Dmitry Stogov wrote: > > Only one note. I would prefer to use "," instead of "|" as a class name > separator. > Especially if "Union types" are not accepted. > The rest should be fine. > +1 from me as well on that. We could have that change as

Re: [PHP-DEV] [VOTE] Catching Multiple Exception Types

On Tue, Apr 19, 2016 at 6:39 AM, Dmitry Stogov wrote: > Only one note. I would prefer to use "," instead of "|" as a class name > separator. > Especially if "Union types" are not accepted. > The rest should be fine. On the other hand if union types is accepted it makes no sense

Re: [PHP-DEV] RFC: Functional Interfaces

Oh, it's confusing text in the RFC, using the word "Interface" ... that's meant as a placeholder for InterfaceName. Cheers Joe On Tue, Apr 19, 2016 at 1:50 PM, Joe Watkins wrote: > Morning Dmitry, > > In your example, they will do the same thing. > > Anon classes

Re: [PHP-DEV] RFC: Functional Interfaces

Morning Dmitry, In your example, they will do the same thing. Anon classes don't have lexical scope, I have a patch for that, and an RFC, I'm just tidying it. Even when anon classes do have lexical scope, there is value in being able to implement these kinds of interfaces using only a

Re: [PHP-DEV] [VOTE] Catching Multiple Exception Types

Only one note. I would prefer to use "," instead of "|" as a class name separator. Especially if "Union types" are not accepted. The rest should be fine. Thanks. Dmitry. From: Bronisław Białek Sent: Sunday, April 17, 2016 19:51 To:

Re: [PHP-DEV] RFC: Functional Interfaces

Are $cb1 and $cb2 going to be the same (do the same)? Is this just a new syntax sugar, or a really new feature? According to implementation, I think, you shouldn't extend "zend_closure" with "interface". If this is a sugar, lets implement it as a sugar (without VM changes). But may be I

Re: [PHP-DEV] Final properties

> On 16 Apr 2016, at 11:19 , Lester Caine wrote: > > On 16/04/16 06:56, André Rømcke wrote: This actually summarises many of the problems all of these 'extras' are creating for very little gain. 'Seconds' is a 'Traditional Property' so is untyped and if

Re: [PHP-DEV] [VOTE] Catching Multiple Exception Types

Hello, Representing the Hoa project community, we have voted yes. Not everyone was agree (60% yes, 40% no), but my vote reflects the average. Main argument in favor of no: * Encourage badly designed API. Main argument in favor of yes: * This is not an edge case when dealing with badly

RE: [PHP-DEV] [VOTE] Catching Multiple Exception Types

> -Original Message- > From: Derick Rethans [mailto:der...@php.net] > Sent: Monday, April 18, 2016 6:18 PM > To: Marco Pivetta > Cc: Dan Ackroyd ; Bronisław Białek > ; PHP internals > Subject: Re:

RE: [PHP-DEV] Re: Improving PHP's type system

> -Original Message- > From: Larry Garfield [mailto:la...@garfieldtech.com] > Sent: Friday, April 15, 2016 9:13 PM > To: internals@lists.php.net > Subject: Re: [PHP-DEV] Re: Improving PHP's type system > > On 4/15/16 12:28 PM, Christoph Becker wrote: > > On 15.04.2016 at 17:42, Larry

Re: [PHP-DEV] Re: Typed properties patch

On 04/18/2016 09:37 PM, Stanislav Malyshev wrote: Hi! right. I don't see any reasons for types, if they are not guaranteed anyway. Well, we already have parameter types, and they are not guaranteed either - you can reassign variables. They guarantee the type of argument on function entry.

Re: [PHP-DEV] Re: Improving PHP's type system

On 4/18/16 4:34 AM, Tony Marston wrote: I repeat, where was the insult in the post in question? What exactly were the insulting words? I chose just one example: > Those who cannot write effective software without these "clever" > additions to the language are doing nothing but announcing

RE: [PHP-DEV] [VOTE] Catching Multiple Exception Types

> -Original Message- > From: Stanislav Malyshev [mailto:smalys...@gmail.com] > Sent: Tuesday, April 19, 2016 8:11 AM > To: Larry Garfield ; internals@lists.php.net > Subject: Re: [PHP-DEV] [VOTE] Catching Multiple Exception Types > > > > I do agree with the