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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hey,
> Am 29.04.2016 um 21:58 schrieb Sara Golemon :
>
> 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
Thanks for proposing, so that I am able to show what I don't like abo
On 04/29/2016 06:37 PM, Bob Weinand wrote:
Hey,
Am 29.04.2016 um 21:58 schrieb Sara Golemon :
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
Thanks for proposing, so that I a
Hey,
to me recursion and pipe operator looks really hard to read, I guess this is
faster and better readable:
foreach (scandir($arg) as $x) {
if ($x == '.' || $x == '..') {
continue;
}
$x = $arg . '/' . $x;
// inline getFileArg ...
$allFiles[] = $x;
}
Regards
Thomas
Bob Weinand
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 a lot of fun in inventing cool signs like |> an
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
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()
> |> parseReq
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
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 eve
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.
> > https://wiki.php.net/rfc/pipe-ope
> 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
http://paul-m-jones.com
--
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
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. That video simply assu
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
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
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 17
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 differe
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 formatt
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 possi
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
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 m
:(
Sent from my android device so quoting is crap ... need to kill these painful
email clients!
-Original Message-
From: les...@lsces.co.uk
To: internals@lists.php.net, Larry Garfield
Sent: Sat, 30 Apr 2016 19:35
Subject: Re: [PHP-DEV] [RFC] Pipe Operator
However,
passing an array to
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 rather than a null retur
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 ba
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 ba
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 i
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 left
On 01/05/16 00:20, Dan Ackroyd wrote:
> Personally, I always use semantically meaningful variable names, as
> they make life so much easier for any person who needs to read the
> code.
AND one can easily see if there are points in the sequence where one
does need to handle alternate results. I wil
Ho Rowan,
Le 01/05/2016 01:14, Rowan Collins a écrit :
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
On 30 April 2016 at 07:49, Marco Pivetta wrote:
> Here's the pseudo-code for a typical request/response dispatch cycle:
Hi Marco,
Could you clarify something for me?
If I submitted a pull-request to you, with variables named like this:
$v = buildRequest();
$v = validate($v);
$v = convertToComm
On 01/05/16 15:39, Dan Ackroyd wrote:
> Marco wrote:
>> > Relevant: https://youtu.be/UvD1VjRvGIk
> I could imagine how having inline branches could be a useful thing for
> functional programming, for various scenarios, including being able to
> 'inline' error handling, to be nearer the source of er
Le dimanche 1 mai 2016, 00:20:45 Dan Ackroyd a écrit :
> However, it is not the proposed new syntax that makes the code more
> readable - it is solely due to writing it in the correct order that
> makes the code more readable. This can be done using current PHP
> syntax, so that the code is:
>
> $
On 30/04/16 20:57, Sara Golemon wrote:
> 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 han
On Mon, May 2, 2016 at 12:56 AM, Michael Wallner wrote:
> On 30/04/16 20:57, Sara Golemon wrote:
>> What follows is a terrible idea and I don't mean to propose it as a
>> solution, but to spark further conversation:
>>
>> $result = getData()
>> ?> doStuffWith($$)
>
> I thought this was the "PHP,
On 04/30/2016 01:05 PM, Larry Garfield wrote:
On 04/29/2016 07:19 PM, Stanislav Malyshev wrote:
In a way... Sara, this syntax feels like it's only one step removed from
promises; if any of the chained steps involve IO, it becomes basically
what promises are for. Am I barking down the wrong tree,
On 04/30/2016 06:14 PM, Rowan Collins wrote:
On 29/04/2016 20:58, Sara Golemon wrote:
Let's say I want to add a condition just before getFileArg(); with the
current version I've got to:
- go to the beginning of the chain, and assign to something other than $ret
- go to where I want to break the c
On 3 May 2016 at 10:57, Stephen Coakley wrote:
> On 04/30/2016 06:14 PM, Rowan Collins wrote:
>
>> On 29/04/2016 20:58, Sara Golemon wrote:
>> Let's say I want to add a condition just before getFileArg(); with the
>> current version I've got to:
>> - go to the beginning of the chain, and assign t
On Mon, May 2, 2016 at 5:57 PM, Stephen Coakley wrote:
> Could you use a closure instead to accomplish this? (Again yes, Sara could
> you clarify if this is permitted?)
>
> $ret = scandir($arg)
> |> array_filter($$, function($x) { return $x !== '.' && $x != '..';
> })
> |> array_ma
On 03/05/16 05:49, Sara Golemon wrote:
> It's way more readable in the pipe syntax version, but it's
> overloading a single statement in both places.
The rop examples show another style of working BUT it only really
changes the way of ordering SOME elements of the code. And the pipe
operator is on
Am 30.04.2016 um 01:37 schrieb Bob Weinand:
> TL;DR:
> -1: The |> pipe operator encourages a write-only style.
I second that emotion.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I am very much in favour of this. I would typically write the example with
an intermediate variable to avoid all the sad nesting.
$files = scandir($arg);
$files = array_filter($files, function ($x) { return $x !== '.' && $x !==
'..'; });
$files = array_map(function ($x) use ($arg) { return $arg .
Stephen Coakley wrote on 03/05/2016 01:57:
On 04/30/2016 06:14 PM, Rowan Collins wrote:
The basic pattern would be:
|=> $tempVar; // terminate the chain and capture the value
// do stuff with $tempVar
$tempVar // restart the chain
So:
scandir($arg)
|> array_filter($$, function($x) { retu
On 5/3/2016 4:53 AM, Terry Cullen wrote:
> Doesn't Nikic's scalar objects (https://github.com/nikic/scalar_objects)
> more or less achieve the same thing while also cleaning up the std lib?
>
> $ret = scandir($arg)
> ->filter(function(){})
> ->map(function(){})
> ->merge($someOtherArr
On Tue, May 3, 2016 at 9:30 AM, Fleshgrinder wrote:
> On 5/3/2016 4:53 AM, Terry Cullen wrote:
>> Doesn't Nikic's scalar objects (https://github.com/nikic/scalar_objects)
>> more or less achieve the same thing while also cleaning up the std lib?
>>
>> $ret = scandir($arg)
>> ->filter(function(
On 03/05/16 19:12, Sara Golemon wrote:
> I like the scalar objects approach as well. Heck, I wrote one three
> years ago: https://github.com/sgolemon/objectifier but I don't think
> it solves the same problem space as pipe chaining.
Which does beg the question ... "Just how many problem spaces ar
On Tue, May 3, 2016 at 11:29 AM, Lester Caine wrote:
> Which does beg the question ... "Just how many problem spaces are
> currently under discussion?" ... There is a space for some additional
> extensions that provided experimental solutions to some of the perceived
> problems which will then all
On 5/3/2016 8:12 PM, Sara Golemon wrote:
> The difference with scalar objects is:
> A) We need to agree on what methods these objects are going to have.
> ((And we won't agree))
>
The nice thing here is that we could start with the things that we agree
on and develop it from there further.
On 5/
On Tue, May 3, 2016 at 11:36 AM, Fleshgrinder wrote:
> On 5/3/2016 8:12 PM, Sara Golemon wrote:
>> The difference with scalar objects is:
>> A) We need to agree on what methods these objects are going to have.
>> ((And we won't agree))
>>
>
> The nice thing here is that we could start with the thi
On 5/3/2016 8:45 PM, Sara Golemon wrote:
>> The pipe operator is also just a work around for poorly designed
>> libraries in this case and yields more poorly designed libraries.
>>
> Pretending that poorly designed libraries exist is naîve. PHP is
> dominated by poorly designed software but it man
On Tue, May 3, 2016 at 11:52 AM, Fleshgrinder wrote:
> On 5/3/2016 8:45 PM, Sara Golemon wrote:
>> Pretending that poorly designed libraries exist is naîve.
>>
> I really do not know what you want to tell me with that first sentence.
>
Ooops, missed a negation when I typed it out.
"Pretending tha
On 03/05/16 19:57, Sara Golemon wrote:
> Intermediate variables also add cognitive overhead of their own in
> cataloging all the various intermediates used in a large function. By
> removing the explicit intermediate variables and replacing them with
> unnamed temporaries, the code becomes easier
On 5/3/2016 8:57 PM, Sara Golemon wrote:
> Ooops, missed a negation when I typed it out.
>
> "Pretending that poorly designed libraries DON'T exist is naîve."
>
I am not pretending that they do not exist, quite the contrary, I
explicitly stated that they exist and that I fear that this syntactic
On Tue, May 3, 2016 at 1:28 PM, Fleshgrinder wrote:
> On 5/3/2016 8:57 PM, Sara Golemon wrote:
> > Ooops, missed a negation when I typed it out.
> >
> > "Pretending that poorly designed libraries DON'T exist is naîve."
> >
>
> I am not pretending that they do not exist, quite the contrary, I
> ex
On 5/3/2016 10:22 PM, Ryan Pallas wrote:
> I have to disagree, I haven't seen an example of rewriting the original
> example from the RFC in a more expressive AND readable way. Yes, you can
> use lots of intermediate variables, but this makes the code HARDER to read
> QUICKLY which is entirely the
On Tue, May 3, 2016 at 2:35 PM, Fleshgrinder wrote:
> On 5/3/2016 10:22 PM, Ryan Pallas wrote:
> > I have to disagree, I haven't seen an example of rewriting the original
> > example from the RFC in a more expressive AND readable way. Yes, you can
> > use lots of intermediate variables, but this
Hi Sara,
On Sat, Apr 30, 2016 at 4:58 AM, 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
PHP is not pure OO anyway. This proposal simplifies procedural
On Tue, May 3, 2016 at 12:53 PM, Terry Cullen wrote:
> Doesn't Nikic's scalar objects (https://github.com/nikic/scalar_objects)
> more or less achieve the same thing while also cleaning up the std lib?
>
> $ret = scandir($arg)
> ->filter(function(){})
> ->map(function(){})
> ->merge(
On Sun, May 1, 2016 at 4:05 AM, Larry Garfield
wrote:
>
> In a way... Sara, this syntax feels like it's only one step removed from
> promises; if any of the chained steps involve IO, it becomes basically what
> promises are for. Am I barking down the wrong tree, or is there something
> we could
On 5/3/2016 11:23 PM, Ryan Pallas wrote:
> Waiting for what example? There's been plenty of examples showing how
> existing options, rewritten with |> are easier. If you disagree, that's an
> opinion, other's agree. If people think its better, why not add it for
> them? Like every other feature dis
Hi,
I agree they are bad APIs.
Framework/library developer should provide better API
On Mon, May 9, 2016 at 1:08 AM, Fleshgrinder wrote:
> $request = getGlobals()
> |> parseRequest($$)
> |> buildPsr7Request($$);
should be
require('some.lib');
$request = getRequest();
/* where getReq
Hi!
> "|>" is just a building block for simpler coding. It could be used badly, but
> it helps a lot. Procedural code could be much simpler and readable with "|>".
I don't see how it helps anything. It just replaces clear variable names
with cryptic sequences of characters with no intuitive meani
On 9 May 2016 at 07:37, Stanislav Malyshev wrote:
> Hi!
>
> > "|>" is just a building block for simpler coding. It could be used
> badly, but
> > it helps a lot. Procedural code could be much simpler and readable with
> "|>".
>
> I don't see how it helps anything. It just replaces clear variable
On Sun, May 8, 2016 at 10:37 PM, Stanislav Malyshev wrote:
> I don't see how it helps anything. It just replaces clear variable names
> with cryptic sequences of characters with no intuitive meaning and magic
> semantics invented solely to save a few keystrokes.
>
Yep, that's exactly what "->" doe
Hi!
> I have the feeling that if everyone involved *explicitly* prefixed their
> opinions with "I think that", this would be a better and more fruitful
Is there any other option?
> discussion. *You* think the syntax completely unobvious - that doesn't
> make it so. Clearly others find it much ea
Hi!
> Yep, that's exactly what "->" does. It's just pointless syntactic
No, not really. Calling method on an object is an universally accepted
phrase in many languages. True, not all of them use ->, and for some of
them -> may have other meaning, but if you tell somebody at least
vaguely familia
On 9 May 2016 at 08:45, Stanislav Malyshev wrote:
> Hi!
>
> > I have the feeling that if everyone involved *explicitly* prefixed their
> > opinions with "I think that", this would be a better and more fruitful
>
> Is there any other option?
>
As in "better options"? I don't think so. As in "coul
On Sun, May 8, 2016 at 11:45 PM, Stanislav Malyshev wrote:
>> Yep, that's exactly what "->" does. It's just pointless syntactic
>
> No, not really. Calling method on an object is an universally accepted
> phrase in many languages.
>
I never said it wasn't. I said it was pointless syntactic sugar
Hi!
> Are you willing to argue that PHP should never implement features not
> found commonly in other languages? Because that's where you're going
> with that argument.
No, I'm not and no, I'm not. But I do claim it is unobvious - though
that alone would not be the reason to reject it, but I outl
Hi!
> You lack imagination. Here's three to get you started:
>
> Elixir:
> http://elixir-lang.org/getting-started/enumerables-and-streams.html#the-pipe-operator
> F#: https://msdn.microsoft.com/en-us/library/dd233229.aspx#Anchor_11
> Clojure: https://clojuredocs.org/clojure.core/-%3E
>
> And i
On 05/09/2016 11:41 AM, Sara Golemon wrote:
On Sun, May 8, 2016 at 11:45 PM, Stanislav Malyshev wrote:
Neither of these is true for |>-$$ thing - it does not have any matches
in any languages I can think of.
You lack imagination. Here's three to get you started:
Elixir:
http://elixir-lang.
Hi!
> |> seems like a common symbol to use, but it admittedly does look a
So, usage in one semi-obscure language (F#) and one completely obscure
one (Elixir) - Clojure doesn't use |> - and one proposal for Javascript
now qualifies for "common". And that counting the fact that neither of
them actu
On Mon, May 9, 2016, at 10:21 PM, Stanislav Malyshev wrote:
> Hi!
>
> > |> seems like a common symbol to use, but it admittedly does look a
>
> So, usage in one semi-obscure language (F#) and one completely obscure
> one (Elixir) - Clojure doesn't use |> - and one proposal for Javascript
> now qu
Hi!
> If the issue is $$ feels too Perl like, what is the alternative? Is
> there another way to chain methods cleanly?
Well, that's a loaded question. It presumes we already agreed on needing
to chain methods using special syntax outlined in the RFC - which we
didn't - and the only problem is
On Thu, May 12, 2016 at 1:19 AM, Larry Garfield
wrote:
> On Mon, May 9, 2016, at 10:21 PM, Stanislav Malyshev wrote:
> > Hi!
> >
> > > |> seems like a common symbol to use, but it admittedly does look a
> >
> > So, usage in one semi-obscure language (F#) and one completely obscure
> > one (Elixir
Hi Larry,
On Thu, May 12, 2016 at 8:19 AM, Larry Garfield wrote:
> On Mon, May 9, 2016, at 10:21 PM, Stanislav Malyshev wrote:
>> Hi!
>>
>> > |> seems like a common symbol to use, but it admittedly does look a
>>
>> So, usage in one semi-obscure language (F#) and one completely obscure
>> one (El
On Thu, May 12, 2016 at 12:33 PM, Davey Shafik wrote:
> On Thu, May 12, 2016 at 1:19 AM, Larry Garfield
> wrote:
>
> > On Mon, May 9, 2016, at 10:21 PM, Stanislav Malyshev wrote:
> > > Hi!
> > >
> > > > |> seems like a common symbol to use, but it admittedly does look a
> > >
> > > So, usage in
> On 12 במאי 2016, at 15:34, Quim Calpe wrote:
>
>> On Thu, May 12, 2016 at 12:33 PM, Davey Shafik wrote:
>>
>> On Thu, May 12, 2016 at 1:19 AM, Larry Garfield
>> wrote:
>>
On Mon, May 9, 2016, at 10:21 PM, Stanislav Malyshev wrote:
Hi!
> |> seems like a common symbol to
On Thu, May 12, 2016 at 5:33 AM, Quim Calpe wrote:
> Is $0 being considered? It's not ideal but is used as "pattern match
> reference" in preg_replace, so we have a (sort of) precedent here. Same for
> $1 (first capturing subpattern).
>
I don't believe it's been brought up yet, and it'd actually r
On Thu, May 12, 2016 at 5:48 AM, Zeev Suraski wrote:
> Whether it's $$ or !# or $0 or any other random symbol doesn't really matter.
>
Agreed.
> Here we have a completely optional syntactic sugar,
> that's not nearly as widely useful as OOP or namespaces.
>
Very few things will be as widely usefu
Hi Sara,
Le 12/05/2016 à 19:02, Sara Golemon a écrit :
On Thu, May 12, 2016 at 5:48 AM, Zeev Suraski wrote:
Whether it's $$ or !# or $0 or any other random symbol doesn't really matter.
Agreed.
Here we have a completely optional syntactic sugar,
that's not nearly as widely useful as OOP or
On Thu, May 12, 2016 at 11:52 AM, François Laupretre wrote:
> If we restrict usage to function calls, we can quite easily get rid of the $$
> by
> associating to each function the position where the lhs must be inserted
> when used as a 'piped function call'.
>
So we'd have to audit all 4k+ funct
Hi Sara,
Le 13/05/2016 à 00:41, Sara Golemon a écrit :
So we'd have to audit all 4k+ functions in the PHP runtime (and
provide a mechanism for defining it on userspace functions)?
That's right, except that, if we only consider functions accepting more
than 1 arg, we just need to check about 1
On Fri, May 13, 2016 at 10:18 AM, François Laupretre wrote:
>> So we'd have to audit all 4k+ functions in the PHP runtime (and
>> provide a mechanism for defining it on userspace functions)?
>
> That's right, except that, if we only consider functions accepting more than
> 1 arg, we just need to c
> On 14/05/2016, at 4:16 AM, Sara Golemon wrote:
>
> On Fri, May 13, 2016 at 10:18 AM, François Laupretre wrote:
>>> So we'd have to audit all 4k+ functions in the PHP runtime (and
>>> provide a mechanism for defining it on userspace functions)?
>>
>> That's right, except that, if we only consi
Le 13/05/2016 à 20:16, Sara Golemon a écrit :
Just to verify, you're suggesting an end-state something like this?
$ret = array(1,2,3)
|> array_map(function($x) { return $x * 2; }) // lhs implicitly
passed as second arg
|> array_sum(); // implicitly passed as only arg (first position)
// $ret
Le 14/05/2016 à 01:36, Simon Welsh a écrit :
I’m not fond of this approach. Take in_array as an example. I have,
in the same file, piped an array in as the second argument and
piped a string in as the first. To have the position of the piped
variable be implicit, you’ll need multiple versions of
On Sat, May 14, 2016 at 3:33 AM, François Laupretre wrote:
> Le 14/05/2016 à 01:36, Simon Welsh a écrit :
\>> Sure, you could try to use the type of the value being passed in,
>> but that ends up much more magic and then you run into the same
>> problem with strpos, or password_verify, or a variet
Le 14/05/2016 à 18:35, Sara Golemon a écrit :
On Sat, May 14, 2016 at 3:33 AM, François Laupretre wrote:
Le 14/05/2016 à 01:36, Simon Welsh a écrit :
\>> Sure, you could try to use the type of the value being passed in,
but that ends up much more magic and then you run into the same
problem w
Le 13/05/2016 à 20:16, Sara Golemon a écrit :
for a potential solution to such a long-time issue as argument ordering
sadness, IMHO, it's worth the pain. I am currently doing it and I'll send
you the list when it is ready.
Awesome. Even if not used in this feature, it could potentially be
usef
On 05/14/2016 07:42 PM, François Laupretre wrote:
Le 13/05/2016 à 20:16, Sara Golemon a écrit :
for a potential solution to such a long-time issue as argument ordering
sadness, IMHO, it's worth the pain. I am currently doing it and I'll
send
you the list when it is ready.
Awesome. Even if n
Le 16/05/2016 à 03:33, Larry Garfield a écrit :
This still sounds awfully complicated to me. I would far, far prefer
the $$ syntax to special casing function aliases just to dance around
it. If we had a short-function syntax then requiring a piped function
to have only a single argument would
On Mon, May 16, 2016 at 2:17 AM, François Laupretre wrote:
> Le 16/05/2016 à 03:33, Larry Garfield a écrit :
>> This still sounds awfully complicated to me. I would far, far prefer
>> the $$ syntax to special casing function aliases just to dance around
>> it. If we had a short-function syntax t
Hi Sara,
On Apr 30, 2016 3:11 AM, "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
After I first read the rfc my immediate feeling was negative. Yet
Not sure if it's already been mentioned, but I've noticed this operator
would be useful when you want to modify something but need to transform it
before and after.
For example, I have a class that serializes/deserializes arrays of strings,
and I need to modify the array that it has encoded. The c
On 17/05/2016 11:55, Jesse Schalken wrote:
$id = $id
|> StringList::decode($$)
|> array_replace($$, $replace)
|> StringList::encode($$);
To reiterate my comments from earlier in the thread, I think the "$id =
$id" looks really weird here, and spoils the step-by-step layout - and,
Le 16/05/2016 à 19:53, Sara Golemon a écrit :
I think you're making a false equivalence here. One can see argument
ordering consistency as a serious problem without seeing a Heath
Robinson version of call chaining as the solution to it.
I appreciate that you want to seize onto any opportunity
On Tue, May 17, 2016 at 6:15 AM, François Laupretre
wrote:
>
>
>
>> The question of function aliases is not so serious because we'll need very
>>> few. Almost every functions have only one 'natural' argument to
>>> substitute
>>> as lhs. I'm not sure I understand what you mean with 'but only in ce
On Tue, May 17, 2016 at 9:14 PM, Rowan Collins
wrote:
> To reiterate my comments from earlier in the thread, I think the "$id =
> $id" looks really weird here, and spoils the step-by-step layout - and, in
> this case, the symmetry.
>
We have the same thing already when chaining methods on value/
On 17/05/2016 13:48, Jesse Schalken wrote:
On Tue, May 17, 2016 at 9:14 PM, Rowan Collins mailto:rowan.coll...@gmail.com>> wrote:
To reiterate my comments from earlier in the thread, I think the
"$id = $id" looks really weird here, and spoils the step-by-step
layout - and, in this c
On Tue, May 17, 2016 at 4:14 AM, Rowan Collins wrote:
> On 17/05/2016 11:55, Jesse Schalken wrote:
> $id
> |> StringList::decode($$)
> |> array_replace($$, $replace)
> |> StringList::encode($$)
> |> $id;
>
>
> Sara, what do you think of this tweak, and my subsequent suggestion that
1 - 100 of 129 matches
Mail list logo
