Re: [PHP-DEV] [RFC] Nullable Types

On Sun, Apr 24, 2016 at 2:58 AM, Levi Morrison wrote: > On Sat, Apr 23, 2016 at 10:40 AM, Quim Calpe wrote: > > Option is no better than a union type with null[1]. If a language > requires an option to be unwrapped then it can do the same with some > type or null. This is what Swift does. These

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

Hi! > https://wiki.php.net/rfc/attributes I've read the proposal and I like the idea of reviving the attributes idea and the simplicity of the approach. I have the following questions for it: - Namespacing. Since the attribute names are not processed in any way according to spec, it may be rath

Re: [PHP-DEV] Misspelled word

Sorry fixed it didn't notify the list (seemed like useless noise): https://wiki.php.net/rfc?do=revisions On Apr 25, 2016 03:56, "Good Guy" wrote: > On 25/04/2016 01:13, Gregg Taylor wrote: > >> The word person is misspelled as perason on this page: >> https://wiki.php.net/rfc in the note near the

Re: [PHP-DEV] Misspelled word

On 25/04/2016 01:13, Gregg Taylor wrote: The word person is misspelled as perason on this page: https://wiki.php.net/rfc in the note near the top Is this what you are talking about? Person Text

[PHP-DEV] Misspelled word

The word person is misspelled as perason on this page: https://wiki.php.net/rfc in the note near the top

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

Hey Levi, TL:DR, if we can reserve some syntax for annotations that will be used by the PHP Engine, that would cover my concern. On 24 April 2016 at 17:57, Levi Morrison wrote: > isn't `@attr()` 100% valid user-land code today that can precede Er, yes it is! I didn't put too much thought the

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

On 4/24/2016 6:57 PM, Levi Morrison wrote: > Genuine question[1]: how is @attr() different than `<>`? Also, > isn't `@attr()` 100% valid user-land code today that can precede > function or constant declarations? > > [1] I don't like that I have to make that explicit but it is what it is. > ROF

Re: [PHP-DEV] PHP 7.1 roadmap

Hi Anatol, Sounds good to me. Cheers Joe On Sun, Apr 24, 2016 at 5:47 PM, Anatol Belski wrote: > Hi, > > > -Original Message- > > From: Pierre Joye [mailto:pierre@gmail.com] > > Sent: Sunday, April 24, 2016 11:46 AM > > To: Davey Shafik > > Cc: Anatol Belski ; Julien Pauli ; > Sco

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

On Sun, Apr 24, 2016 at 10:03 AM, Dan Ackroyd wrote: > On 21 April 2016 at 22:13, Dmitry Stogov wrote: >> Hi, >> >> >> I would like to present an RFC proposing support for native annotation. >> > > Hi Dmitry, > > Although everyone will have an opinion about the syntax, I think there > is one crit

RE: [PHP-DEV] PHP 7.1 roadmap

Hi, > -Original Message- > From: Pierre Joye [mailto:pierre@gmail.com] > Sent: Sunday, April 24, 2016 11:46 AM > To: Davey Shafik > Cc: Anatol Belski ; Julien Pauli ; > Scott > Arciszewski ; Anatol Belski ; PHP > internals ; Ferenc Kovacs ; > Stanislav Malyshev > Subject: Re: [PHP-D

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

On 21 April 2016 at 22:13, Dmitry Stogov wrote: > Hi, > > > I would like to present an RFC proposing support for native annotation. > Hi Dmitry, Although everyone will have an opinion about the syntax, I think there is one criticism that should be thought about; the chosen syntax isn't future ex

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

I think it's much less work to parse <<>> as comments in 7.0 instead of having every framework releasing and supporting two packages. In the past, frameworks released new major versions to use new PHP features, but this came with a lot of incompatibilities and many companies skipped the migratio

Re: [PHP-DEV] [RFC] Nullable Types

Hi Thomas, Sorry for the delay. I was traveling last week. By convention `return;` in PHP is an early return for a function that returns nothing at all. I think it can be confusing when reading a function to look at a `return;` line and have to remember to look elsewhere to discover what that mea

RE: [PHP-DEV] [RFC] PHP Attributes

Hi! > From: dmi...@zend.com >> On 04/22/2016 02:46 PM, Thomas Punt wrote: >> Hi Dmitry! >> >> Just a couple of comments on this: >> >> 1. I'd definitely reuse the php-ast extension for parsing the code into an >> AST. It performs a number of transformations on PHP's underlying AST >> that make it

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

Le ven. 22 avr. 2016 à 00:10, Dan Ackroyd a écrit : > On 20 April 2016 at 23:16, Patrick ALLAERT wrote: > > > It's also perfectly possible to make all those Exceptions implement a > > "MatchingFailedException" interface (even empty). > > Apologies for continuing the conversation, even after the

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

On 4/24/2016 2:54 PM, Fleshgrinder wrote: > Another way to illustrate what I mean: > > The feature will be used /to annotate/ (add metadata) and the so > /annotated/ data has additional /attributes/ afterwards. > > Trying building the sentence if the feature is called /attributes/. > > @entity

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

Another way to illustrate what I mean: The feature will be used /to annotate/ (add metadata) and the so /annotated/ data has additional /attributes/ afterwards. Trying building the sentence if the feature is called /attributes/. @entity @invariant final class A { @inject private s

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

I am not arguing against the RFC nor the feature itself, on the contrary, I like it. I just do not like certain aspects and design decisions of it; that is all. Configuration and AOP are the best usecases for annotations and those should be stressed in the RFC. They are not mentioned at all! Anot

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

On 4/24/2016 1:58 PM, Benjamin Eberlei wrote: > The article *you* reference about attributes lists C# attributes as the > *first* example. > > And defines an attribute as: > > "For clarity, attributes should more correctly be considered metadata > . An attr

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

On Sun, Apr 24, 2016 at 1:55 PM, Fleshgrinder wrote: > On 4/24/2016 1:36 PM, Benjamin Eberlei wrote: > > On Sun, Apr 24, 2016 at 10:24 AM, Fleshgrinder > wrote: > > > >> The invariant could also be added as an additional branch to the class > >> instead of a method, since it would not work like

RE: [PHP-DEV] [RFC] PHP Attributes

> -Original Message- > From: Fleshgrinder [mailto:p...@fleshgrinder.com] > Sent: Sunday, April 24, 2016 2:49 PM > To: Zeev Suraski ; Sebastian Bergmann > > Cc: internals@lists.php.net > Subject: Re: [PHP-DEV] [RFC] PHP Attributes > > On 4/24/2016 1:00 PM, Zeev Suraski wrote: > > > > > >

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

On Sun, Apr 24, 2016 at 1:48 PM, Fleshgrinder wrote: > On 4/24/2016 1:00 PM, Zeev Suraski wrote: > > > > > >> -Original Message- > >> From: Sebastian Bergmann [mailto:sebast...@php.net] > >> Sent: Sunday, April 24, 2016 12:14 PM > >> To: internals@lists.php.net > >> Subject: Re: [PHP-DEV]

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

On 4/24/2016 1:36 PM, Benjamin Eberlei wrote: > On Sun, Apr 24, 2016 at 10:24 AM, Fleshgrinder wrote: > >> The invariant could also be added as an additional branch to the class >> instead of a method, since it would not work like a method. >> >> class A {} invariant {} >> >> function f() {}

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

On 4/24/2016 1:00 PM, Zeev Suraski wrote: > > >> -Original Message- >> From: Sebastian Bergmann [mailto:sebast...@php.net] >> Sent: Sunday, April 24, 2016 12:14 PM >> To: internals@lists.php.net >> Subject: Re: [PHP-DEV] [RFC] PHP Attributes >> >> On 04/21/2016 11:13 PM, Dmitry Stogov wro

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

On Sun, Apr 24, 2016 at 10:24 AM, Fleshgrinder wrote: > The invariant could also be added as an additional branch to the class > instead of a method, since it would not work like a method. > > class A {} invariant {} > > function f() {} require {} ensure {} > > This would also align nicely wi

RE: [PHP-DEV] [RFC] PHP Attributes

> -Original Message- > From: Sebastian Bergmann [mailto:sebast...@php.net] > Sent: Sunday, April 24, 2016 12:14 PM > To: internals@lists.php.net > Subject: Re: [PHP-DEV] [RFC] PHP Attributes > > On 04/21/2016 11:13 PM, Dmitry Stogov wrote: > > I would like to present an RFC proposing sup

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

On Sun, Apr 24, 2016 at 1:09 AM, Thomas Bley wrote: > The <<>> syntax comes with the problem that previous versions cannot > ignore it on parsing. > So poeple write new frameworks for 7.0 which cannot be parsed in 5.x, then > they write new frameworks for 7.1 which cannot be parsed with 7.0 and 5

Re: [PHP-DEV] PHP 7.1 roadmap

On Sun, Apr 24, 2016 at 7:28 AM, Davey Shafik wrote: > On Sat, Apr 23, 2016 at 11:06 AM, Anatol Belski > wrote: > >> Hi Davey, >> >> > -Original Message- >> > From: m...@daveyshafik.com [mailto:m...@daveyshafik.com] On Behalf Of Davey >> > Shafik >> > Sent: Friday, April 22, 2016 5:03 AM

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

On 04/21/2016 11:13 PM, Dmitry Stogov wrote: > I would like to present an RFC proposing support for native annotation. Dmitry, please use "annotation" as the name for this feature and not "attribute". We already have attributes: it's what we use to store data in objects. And while some people ca

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

The invariant could also be added as an additional branch to the class instead of a method, since it would not work like a method. class A {} invariant {} function f() {} require {} ensure {} This would also align nicely with closures and anonymous classes, which is kind a problematic with a

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

On 24/04/16 08:53, Fleshgrinder wrote: > That is the nature of a feature release, you find many of those in any > PHP feature release. Think of for instance `yield`, directly results in > a parse error in older PHP versions. There are two types of 'BC' problems which need to be catered for. The ea

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

On 4/24/2016 1:48 AM, Benoit Schildknecht wrote: > If I was a popular framework creator, this wouldn't stop me. I would > release two packages : one for 7.0, another one for 7.1. And the 7.0 one > would be the 7.1 one that has been processed through a script to remove > any <<>> syntax, or to trans