Re: [PHP-DEV] [RFC] Pipe Operator

On 29/04/2016 20:58, Sara Golemon wrote: This is one of my favorites out of HackLang. It's pure syntactic sugar, but it goes a long way towards improving readability. https://wiki.php.net/rfc/pipe-operator I like this idea, for the same reason I like chained method calls - the code reads

Re: [PHP-DEV] Attributes/Annotations Case Study: Drupal

On 30/04/2016 23:45, Stanislav Malyshev wrote: Oh, of course you can have methods, but then it is strange conceptually - you have a normal class, which some other part of the language just uses for something else that classes are not routinely used for. I.e., does it call a constructor? When?

Re: [PHP-DEV] [RFC] Pipe Operator

Hi Sara, I have to take exception to the section of the RFC titled "File collection Example", where you take a block of code and re-write it to be more readable, using the RFC's syntax. However, it is not the proposed new syntax that makes the code more readable - it is solely due to writing it

Re: [PHP-DEV] PHP Attributes -> docBloc alternatives ...

Hi! > As far as I know, the PHP core has never dictated docblock contents, or > any other aspect of coding style. Such decisions are up to "the True, but having common standards which include docblocks in not unheard of in programming ecosystems. In Java world, prescribing docblock contents -

Re: [PHP-DEV] Attributes/Annotations Case Study: Drupal

Hi! > What would prevent the class from having methods? > > class MyAnnotation > { > public $foo; > public $bar; > public function doStuff() { ... } > } Oh, of course you can have methods, but then it is strange conceptually - you have a normal class, which some other part of the language just

Re: [PHP-DEV] Forbid dynamic calls to scope introspection/modification functions

Hi! > I think it's better to keep this email as RFC, at least for documentation of > BC break purpose. > I'm not sure if we need 2 week discussion + 2 weeks voting for this. > I think 1 week voting should be enough? It should be at least 2 weeks discussion, as it's a language change, as for

Re: [PHP-DEV] Attributes/Annotations Case Study: Drupal

On 30/04/2016 23:14, Stanislav Malyshev wrote: $def instanceof MyAnnotation; //TRUE That looks fine, however the problem is that if MyAnnotation is a class, then PHP does not have multiple inheritance, so it's the only class it can be. And given that your class has no methods, $def has no

Re: [PHP-DEV] Attributes/Annotations Case Study: Drupal

Hi! > <> Here you have essentially created a named parameter syntax. That may be a problem later, especially if we do implement named parameters and this won't be the syntax we choose. > $def instanceof MyAnnotation; //TRUE That looks fine, however the

Re: [PHP-DEV] Attributes/Annotations Case Study: Drupal

On 04/30/2016 04:12 PM, Stanislav Malyshev wrote: Hi! That you for bringing real usage examples. This is an interesting point to consider. Reading through it, however, I can't help but wonder why these things are not just data? I mean, why they are kept in the comments? If there are reasons

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

On 30/04/2016 12:09, Fleshgrinder wrote: Erm, actually I did not claim anything [...] I previously claimed that Microsoft does a perfect job. Just thought I'd point out this contradiction. That claim was based on the fact that the feature is called "Data Annotations" and that one can

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

Le 17/04/2016 18:51, Bronisław Białek a écrit : We've opened the vote on https://wiki.php.net/rfc/multiple-catch Hi, At AFUP, we would be +1 on this RFC. Basically: small feature that should not break existing code and can be useful in some situations. Thanks for your work on this! --

Re: [PHP-DEV] Attributes/Annotations Case Study: Drupal

Hi! That you for bringing real usage examples. This is an interesting point to consider. Reading through it, however, I can't help but wonder why these things are not just data? I mean, why they are kept in the comments? If there are reasons like performance, there could be solutions developed,

Re: [PHP-DEV] [RFC] Pipe Operator

Hi! > See, I take that quote in the exact opposite direction. I find chaining > methods to be far, far less "clever" than deeply nesting them inside If you tell me that syntax like "foo() |> bar($$)" is more natural or intuitive or readily understandable to anyone with any programming and PHP

Re: [PHP-DEV] [RFC] Pipe Operator

Hi! > See, I take that quote in the exact opposite direction. I find chaining > methods to be far, far less "clever" than deeply nesting them inside If you tell me that syntax like "foo() |> bar($$)" is more natural or intuitive or readily understandable to anyone with any programming and PHP

Re: [PHP-DEV] [RFC] Pipe Operator

On Sat, Apr 30, 2016 at 11:41 AM, wrote: > God I hate crap software ... TRYING to reply without top post ... but Samsung > is incapable! > > What I was trying to comment on was that trapping that no result is returned > may be what is needed, so handling the empty array

Re: [PHP-DEV] [RFC] Pipe Operator

God I hate crap software ... TRYING to reply without top post ... but Samsung is incapable! What I was trying to comment on was that trapping that no result is returned may be what is needed, so handling the empty array rather than a null return just means having to remember what you do use :(

Re: [PHP-DEV] [RFC] Pipe Operator

However, passing an array to array_filter() then passing the result to array_map() is always type safe (because array_filter still returns an array even if it filters down to 0 items), and array_map on an empty array is essentially a no-op, so I'm comfortable doing so, and wish I could do so

Re: [PHP-DEV] [RFC] Pipe Operator

On 04/29/2016 07:19 PM, Stanislav Malyshev wrote: Hi! This is one of my favorites out of HackLang. It's pure syntactic sugar, but it goes a long way towards improving readability. https://wiki.php.net/rfc/pipe-operator I think this takes the syntax too much towards Perl 6 direction. There is

Re: [PHP-DEV] Attributes/Annotations Case Study: Drupal

On 04/29/2016 11:54 PM, Pierre Joye wrote: Hi Larry, On Apr 30, 2016 6:48 AM, "Larry Garfield" wrote: Most of the examples that have been given so far are either trivial boolean flags or data validation rules to be evaled. In practice, very little of Drupal's use of

Re: [PHP-DEV] zend_pass_function/zif_pass

On Sat, Apr 30, 2016 at 7:12 PM, Derick Rethans wrote: > Hi! > > I'm trying to make Xdebug up to date with master again, and after fixing > the static changes that Dmitry highlighted, I am still baffled by > something else. > > My function traces now have an extra entry for each

[PHP-DEV] zend_pass_function/zif_pass

Hi! I'm trying to make Xdebug up to date with master again, and after fixing the static changes that Dmitry highlighted, I am still baffled by something else. My function traces now have an extra entry for each constructor - even for classes that have no constructor, such as stdClass. Code

Re: [PHP-DEV] [RFC] Pipe Operator

On 30/04/16 16:03, rich gray wrote: >> As I said in the message ... no problem if you simply have a SINGLE >> pathway through the code. That video simply assumes that anything that >> is not success is an error. MUCH of my code base has turntables or three >> way switches which in addition to

Re: [PHP-DEV] [RFC] Pipe Operator

On 4/30/2016 5:51 PM, Fleshgrinder wrote: > $ret = scandir($arg) > |> array_filter($$, function($x) { return $x !== '.' && $x != '..'; }) > |> array_map(function ($x) use ($arg) { return $arg . '/' . $x; }, $$) > |> getFileArg($$) > |> array_merge($ret, $$); This should actually be

Re: [PHP-DEV] [RFC] Pipe Operator

On 4/30/2016 5:23 PM, Marco Pivetta wrote: > This feature has nothing to do with fluent interfaces, nor has their flaws. > The readability of piped processing for functional code is simply a > no-brainer here, and doesn't require any API changes in function signatures > either: it is not "a

Re: [PHP-DEV] [RFC] Pipe Operator

This feature has nothing to do with fluent interfaces, nor has their flaws. The readability of piped processing for functional code is simply a no-brainer here, and doesn't require any API changes in function signatures either: it is not "a different way of doing the same thing". On Apr 30, 2016

Re: [PHP-DEV] [RFC] Pipe Operator

On 4/30/2016 8:49 AM, Marco Pivetta wrote: > I think this is much more readable/clear than any event-driven or > procedural approach. > We know exactly what is going on, we will get clear stack traces (this > could need some fine-tuning of the current PR - I didn't try it out yet) > and we will be

Re: [PHP-DEV] [RFC] Pipe Operator

On 30/04/2016 15:43, Lester Caine wrote: As I said in the message ... no problem if you simply have a SINGLE pathway through the code. That video simply assumes that anything that is not success is an error. MUCH of my code base has turntables or three way switches which in addition to possible

Re: [PHP-DEV] [RFC] Pipe Operator

On 30 Apr 2016 16:43, "Lester Caine" wrote: > > On 30/04/16 14:57, Marco Pivetta wrote: > > Relevant: https://youtu.be/UvD1VjRvGIk > > Trimming the now useless error code > > As I said in the message ... no problem if you simply have a SINGLE > pathway through the code.

Re: [PHP-DEV] [RFC] Pipe Operator

On 30/04/16 14:57, Marco Pivetta wrote: > Relevant: https://youtu.be/UvD1VjRvGIk Trimming the now useless error code As I said in the message ... no problem if you simply have a SINGLE pathway through the code. That video simply assumes that anything that is not success is an error. MUCH of

Re: [PHP-DEV] [RFC] Pipe Operator

> On Apr 29, 2016, at 14:58, Sara Golemon wrote: > > This is one of my favorites out of HackLang. It's pure syntactic > sugar, but it goes a long way towards improving readability. > https://wiki.php.net/rfc/pipe-operator I like this a lot. -- Paul M. Jones

Re: [PHP-DEV] [RFC] Pipe Operator

Relevant: https://youtu.be/UvD1VjRvGIk On Apr 30, 2016 15:52, "Lester Caine" wrote: > On 29/04/16 20:58, Sara Golemon wrote: > > This is one of my favorites out of HackLang. It's pure syntactic > > sugar, but it goes a long way towards improving readability. > >

Re: [PHP-DEV] [RFC] Pipe Operator

On 29/04/16 20:58, Sara Golemon wrote: > This is one of my favorites out of HackLang. It's pure syntactic > sugar, but it goes a long way towards improving readability. > https://wiki.php.net/rfc/pipe-operator I can see the attraction, but question it's usability in real time code. It assumes

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

On 4/25/2016 10:31 AM, Dmitry Stogov wrote: > completely disagree. > Each value in multi-value attribute may have its own meaning. e.g. > <> > That is a different example but I think that I misinterpreted it anyways. <> function foo() {} I thought

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

On 4/28/2016 11:15 PM, Stanislav Malyshev wrote: > I think we should not try to be Haskell, Scala and Eiffel at the same > time. DbC is not something most of the users of the language require and > would ever use, unlike Eiifel where it is major part of what the > language is. Giving a possibility

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

On 4/28/2016 9:43 PM, Rowan Collins wrote: > I meant specifically in the context of C#/.net. You claimed a very > specific usage within that framework, but all the articles I can find > refer to them consistently as "attributes" in that context. Event the > Wikipedia article: > >> In the C#

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

> > In this case I would suggest to use class A which leaves room > > open to define lower bounds later on > > IMHO that is bordering on unreadable - all those brackets are really > confusing and hard on the eyes. > I agree, it looks quite ugly :-) Therefore another suggestion: class A

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

Den 2016-04-25 kl. 11:49, skrev Rowan Collins: Patrick ALLAERT wrote on 24/04/2016 14:18: There is just nothing more repeatable or common cases than "resource not found", "method not allowed", "access denied",... They are all non exceptional cases better handled without exceptions and with

Re: [PHP-DEV] [RFC] Pipe Operator

I like the proposal, but readability should be on the forefront of things that need to be done right. Yes, there are people that will make it an unreadable mess, but we have code reformat, so if the syntax is verbose enought to be read at a glance, I'm all for it. +1 as long as syntax gets a hard

RE: [PHP-DEV] [RFC] Pipe Operator

Hi! > From: ocram...@gmail.com > > I would say that this makes the entire functional approach: > > 1. more readable > 2. easier to debug (woah, we can haz line numbers for failures!) > > Here's the pseudo-code for a typical request/response dispatch cycle: > > $request = getGlobals() > |>

Re: [PHP-DEV] PHP Attributes -> docBloc alternatives ...

On Sat, Apr 30, 2016 at 3:52 PM, Lester Caine wrote: > On 30/04/16 09:38, Pierre Joye wrote: >>> Sorry if you didn't spend the last 6+ years of your free time >>> > < >> https://github.com/phpDocumentor/phpDocumentor2/commit/66dc9069085dcea957508f84e9c79eaf4c234586 >>> > >>> >

Re: [PHP-DEV] PHP Attributes -> docBloc alternatives ...

On 30/04/16 09:38, Pierre Joye wrote: >> Sorry if you didn't spend the last 6+ years of your free time >> > < > https://github.com/phpDocumentor/phpDocumentor2/commit/66dc9069085dcea957508f84e9c79eaf4c234586 >> > >> > (yes, that is an import) maintaining an open-source project focused on >> >

Re: [PHP-DEV] PHP Attributes -> docBloc alternatives ...

On Apr 29, 2016 3:42 PM, "Marco Pivetta" wrote: > > Hey Lester, > > Sorry if you didn't spend the last 6+ years of your free time > < https://github.com/phpDocumentor/phpDocumentor2/commit/66dc9069085dcea957508f84e9c79eaf4c234586 > > (yes, that is an import) maintaining an

Re: [PHP-DEV] PHP Attributes -> docBloc alternatives ...

On 29/04/16 18:00, Rowan Collins wrote: >> But in the second example just where does >> the error redirect traffic? At least with in-line checks you control >> flow ... > > A good question. As such, the annotation doesn't execute any code in the > current proposal, it just allows tools to inspect

Re: [PHP-DEV] [RFC] Pipe Operator

I would say that this makes the entire functional approach: 1. more readable 2. easier to debug (woah, we can haz line numbers for failures!) Here's the pseudo-code for a typical request/response dispatch cycle: $request = getGlobals() |> parseRequest($$) |> buildPsr7Request($$); $response