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
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
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
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
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
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
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
> On 7 במאי 2016, at 2:35, Raja Kulasekaran wrote:
>
> Hi,
>
> Sorry If I am asking this question in irrelevent forum.
> Please suggest me the point of direction if not.
>
> I have encrypted php Application codebase which I may or may not have
> access.
>
> So, I would like to know how the ap
Hi everyone,
Voting on Bob and I's RFC for a shorter syntax for list() ran from
2016-04-27 to 2016-05-08, and has now closed.
By 41 votes in favour to none against, the RFC has been approved for PHP
7.1. We will now work towards merging into master.
Votes can be seen on the RFC page:
https
Hi,
On Fri, 2016-05-06 at 19:34 -0400, Raja Kulasekaran wrote:
> Is there any php extension available which help me out to give the
> statistics of
> all the queries execution details ?
if you are on a development machine (thus no unrelated traffic)
something like a query log (in MySQL general_lo
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
On 5/6/2016 8:02 AM, Dmitry Stogov wrote:
> On 05/06/2016 05:06 AM, Jesse Schalken wrote:
>> If you're going to say "do what you want" with regards to annotations,
>> then
>> just let them be a text string. Parsing the annotation as PHP but not
>> evaluating it as PHP seems a very strange and arbit
Hi,
I have been thinking about it and I would be ok with removing _empty_ in
7.1. That inconsistency is quite annoying and I never liked it. If we can
rid of it, that would be great! I realise the BC concern but I see that
more as a limitation and inconsistency between array and object decoding.
I
On Sun, May 8, 2016 at 3:54 PM, Tom Worster wrote:
> On 5/7/16, 1:19 PM, "Nikita Popov" wrote:
>
> >This RFC has one primary vote and one secondary vote. The primary vote
> >determines whether we want to add nullable types to our type system. The
> >secondary vote decides how precisely this will
On 5/7/16, 1:19 PM, "Nikita Popov" wrote:
>This RFC has one primary vote and one secondary vote. The primary vote
>determines whether we want to add nullable types to our type system. The
>secondary vote decides how precisely this will happen, in this instance
>deciding whether nullable types wil
Den 2016-05-06 kl. 21:41, skrev Levi Morrison:
The [RFC for Nullable Types][1] is going to go into the voting phase
soon. There have been a few changes to the RFC in the meantime:
- More example for documentation's sake
- The vote is now split into two parts: one for nullable parameter
ty
16 matches
Mail list logo
