[PHP-DEV] Re: [RFC][VOTE] Session ID without hashing

[Yasuo Ohgaki]

Hi all,

On Sat, Jul 2, 2016 at 4:35 PM, Yasuo Ohgaki  wrote:
> Currently session module uses obsolete MD5 for session ID. With
> CSPRNG, hashing is redundant and needless. It adds hash module
> dependency and inefficient (There is no reason to use hash for CSPRNG
> generated bytes).
>
> This proposal cleans up session code by removing hash.
>
> https://wiki.php.net/rfc/session-id-without-hashing
>
> I set vote requires 2/3 support.
> Please describe the reason why when you against this RFC. Reasons are
> important for improvements!
>
> Thank you!

Thank you for voting and the RFC has passed 13 vs 5.
I'll prepare documents and merge the change in a few days.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] [RFC][VOTE] Enable session.use_strict_mode by default

[Yasuo Ohgaki]

Hi all,

Vote for "Enable session.use_strict_mode by default" RFC has started.

https://wiki.php.net/rfc/session-use-strict-mode

Vote ends 2017/07/19 UTC.

Thank you for voting!

--
Yasuo Ohgaki
yohg...@ohgaki.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Proposal for php7 class method return

[Stanislav Malyshev]

Hi!

> $counter->count();
> $counter->count();
> $counter->count();
> $counter->count();
> echo $counter->getCount();

I still fail to see what's so wrong in this code that it needs a whole
new operator to fix it.

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Proposal for php7 class method return

[Rowan Collins]

On 11/07/2016 21:17, Marco Pivetta wrote:
On 11 July 2016 at 22:15, Rowan Collins > wrote:


Again, it's just different syntax for doing things we can already do.


Spot on! Plus it's something arguably considered a bad idea. I don't 
think that adding language features for this sort of thing is useful. 
Maybe it's even just harmful.


Looking through the reasons given in your blog post, most of them don't 
really apply with a dedicated operator, because they're about the 
*contract*, and a cascade operator is only useful when the contract is 
to return something *other* than the current object.


Specifically, it relies on the assumption that the method is not 
returning a new instance. To adapt one of your examples:


$counter->count();
$counter->count();
$counter->count();
$counter->count();
echo $counter->getCount();
// This relies on count() mutating the current object, probably the 
contract is to return void


The same thing, with ->> as a cascade operator:

echo $counter
->>count()
->>count()
->>count()
->>count()
->getCount();

Or perhaps for clarity, pull the echo separately:

$counter
->>count()
->>count()
->>count()
->>count();
echo $counter->getCount();


The cascade operator is a tool to use *instead of* a fluent interface, 
not *with* it, and it solves a lot of the problems you outlined - 
$counter here can be mocked, wrapped, substituted for different 
implementations, etc, because the ->> operator makes no more assumptions 
than the code was already making.


Regards,

--
Rowan Collins
[IMSoP]


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Cascade Operator (was Re: [PHP-DEV] Proposal for php7 class method return)

[Larry Garfield]

On 07/11/2016 11:30 AM, Rasmus Schultz wrote:

what's the actual added value of this sort of operator?

The only direct value to the language is brevity - mere convenience.

But I think the biggest indirectly added value, is that this will
discourage people from the chainable methods anti-pattern - so this
has value to the community; those who write chainable methods can
stop, and those who want chainable methods can get a wider choice of
libraries that were previously too verbose in use for their taste.


As one of those proponents of chained methods / returning $this, I quite 
like this proposal.  It neatly handles many (although not all) of the 
use cases for method chaining, specifically the most controversial ones, 
while not having any of the same potential issues.  (Eg, when composing 
and delegating the method call to another object, you have to do some 
$this juggling.)  It would not remove the need for all method chaining, 
but it would remove the need for the controversial ones that Rasmus is 
complaining about while letting people like me still write nicely 
compact and readable code. :-)


(Modulo implementation details and debating the operator symbol for a 
few weeks, as per usual.)


--Larry Garfield

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Proposal for php7 class method return

[Marco Pivetta]

On 11 July 2016 at 22:15, Rowan Collins  wrote:

> Again, it's just different syntax for doing things we can already do.
>
>
Spot on! Plus it's something arguably considered a bad idea. I don't think
that adding language features for this sort of thing is useful. Maybe it's
even just harmful.


Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Re: [PHP-DEV] Proposal for php7 class method return

[Rowan Collins]

On 11/07/2016 20:56, Marco Pivetta wrote:

On 11 July 2016 at 21:51, Jesse Schalken  wrote:


does save the verbosity of repeating a variable name, and often saves a
variable altogether:

$blah = new Blah();
$blah->setFoo(1);
$blah->setBaz(2);
$this->setBlah($blah);


becomes

$this->setBlah((new Blah())
 ->setFoo(1)
 ->setBaz(2)
);



Right: to save one variable assignment you now have 3 function calls. I
think I see your problem (if this is about performance) :-P


Huh? There's exactly the same number of function calls. And who said 
this was ever about performance?


Again, it's just different syntax for doing things we can already do. 
Even the object cascade operator is just hiding the assignment to a 
temporary variable - think of it like post-increment:


$bar = $foo; $foo = $foo + 1;
$bar = $foo++;

$bar = $foo; $foo->inc();
$bar = $foo->>inc();

(I'm not suggesting this is a literal use case for the operator, just 
highlighting the parallels; please don't start picking at it.)


Regards,

--
Rowan Collins
[IMSoP]


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Proposal for php7 class method return

[Marco Pivetta]

On 11 July 2016 at 21:51, Jesse Schalken  wrote:

>
> does save the verbosity of repeating a variable name, and often saves a
> variable altogether:
>
> $blah = new Blah();
> $blah->setFoo(1);
> $blah->setBaz(2);
> $this->setBlah($blah);
>
>
> becomes
>
> $this->setBlah((new Blah())
> ->setFoo(1)
> ->setBaz(2)
> );
>
>
Right: to save one variable assignment you now have 3 function calls. I
think I see your problem (if this is about performance) :-P


Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Re: [PHP-DEV] Assign return value of function to property or replace parse error with nice fatal error

[Nikita Popov]

On Mon, Jul 11, 2016 at 9:39 PM, Khawer .  wrote:

> It would be better if we can assign return value of function to property.
>
> If not at least we should generate a nice error message.
>
> Currently when we try to assign return value of function to property we get
> the following error:
> Parse error: syntax error, unexpected '(', expecting ',' or ';' in
> index.php on line 4
>
> We should replace this error with the following error:
> Fatal error: You must assign a static value to property in index.php on
> line 4.
> OR
> Fatal error: Dynamic values cannot be assigned to property in index.php on
> line 4.
>

Since PHP 7 the error message is:

Fatal error: Constant expression contains invalid operations

Nikita

Re: [PHP-DEV] Proposal for php7 class method return

[Jesse Schalken]

On Mon, Jul 11, 2016 at 10:18 PM, Marco Pivetta  wrote:

> Hi Jesse,
>
> `return $this;` is a fairly common anti-pattern. It can be useful in few
> edge-cases, like immutable APIs (CoW) and DSL builders, but it's usually a
> bad idea. I ranted extensively about this at
> https://ocramius.github.io/blog/fluent-interfaces-are-evil/
>

I agree, but nonetheless at the cost of the problems both you (in your blog
post) and I have mentioned, "return $this;" does save the verbosity of
repeating a variable name, and often saves a variable altogether:

$blah = new Blah();
$blah->setFoo(1);
$blah->setBaz(2);
$this->setBlah($blah);


becomes

$this->setBlah((new Blah())
->setFoo(1)
->setBaz(2)
);


Some cascade operator or inline group method call/property set achieves the
same thing, but without all the problems of "return $this;":

$this->setBlah((new Blah())
->>setFoo(1)
->>setBaz(2)
);


$this->setBlah(new Blah() {
setFoo(1),
setBaz(2),
});


$this->setBlah(new Blah() {
foo = 1,
baz = 2,
});

[PHP-DEV] Assign return value of function to property or replace parse error with nice fatal error

[Khawer .]

It would be better if we can assign return value of function to property.

If not at least we should generate a nice error message.

Currently when we try to assign return value of function to property we get
the following error:
Parse error: syntax error, unexpected '(', expecting ',' or ';' in
index.php on line 4

We should replace this error with the following error:
Fatal error: You must assign a static value to property in index.php on
line 4.
OR
Fatal error: Dynamic values cannot be assigned to property in index.php on
line 4.

Re: [PHP-DEV] Cascade Operator (was Re: [PHP-DEV] Proposal for php7 class method return)

[Pedro Cordeiro]

2016-07-11 13:30 GMT-03:00 Rasmus Schultz :

> Regarding syntax - I feel the natural choice, e.g. similar to "." vs
> "..", would be a longer arrow --> but that's ambiguous. (decrement
> operator, greater than operator)
>

Yes, it's ambiguous. It will also get confused for the (in)famous "goes to
operator":
http://stackoverflow.com/questions/1642028/what-is-the-name-of-the-operator

Re: [PHP-DEV] Cascade Operator (was Re: [PHP-DEV] Proposal for php7 class method return)

[Michał Brzuchalski]

11 lip 2016 18:31 "Rasmus Schultz"  napisał(a):
>
> > what's the actual added value of this sort of operator?
>
> The only direct value to the language is brevity - mere convenience.
>
> But I think the biggest indirectly added value, is that this will
> discourage people from the chainable methods anti-pattern - so this
> has value to the community; those who write chainable methods can
> stop, and those who want chainable methods can get a wider choice of
> libraries that were previously too verbose in use for their taste.
>
> > For this sort of chaining I'd propose, in addition to the cascade
operator,
> > the chain operator. This would work like the cascade operator except
that
> > the return of the function is implicitly the first parameter of the next
> > argument in the chain
>
> I don't like this idea, at all - I think we should aim for something
> consistent with other languages. Per the Dart spec:
>
> > A cascaded method invocation expression of the form e..suffix is
equivalent to the expression (t){t.suffix; return t;}(e).
>
> In other words, the expression always evaluates as the object, which
> is fine for most cases, e.g. for everything you're doing with
> chainable methods today - which can't actually return any values,
> since they return $this. Note that something like PSR-7's HTTP
> immutable models are actually factory methods, e.g. use-cases not
> applicable to the cascade operator.
>
> The other marginal use case perhaps is cases where a builder of some
> sort ends with a call to a factory method - this can be done without
> adding a second operator, by using parens in a similar fashion to Dart
> and others, e.g.:
>
> $object = ($builder
> ->>setFoo(1)
> ->>setBar(2)
> ->>setBaz(3)
> )->build();
>
> Or obviously:
>
> $builder
> ->>setFoo(1)
> ->>setBar(2)
> ->>setBaz(3);
>
> $object = $builder->build();
>
> Regarding syntax - I feel the natural choice, e.g. similar to "." vs
> "..", would be a longer arrow --> but that's ambiguous. (decrement
> operator, greater than operator)
>
> The proposed |> operator looks horrible and is very awkward to type,
> at least on both American and Danish keyboard - I use both. (it reads
> like "or greater than" in my mind, so much so that glancing over
> Sara's proposal earlier, I didn't even understand what it was.)
>
> Would something like ->> be ambiguous as well? That's fairly close too
> - a double-headed arrow, not unlike the double dots of other
> languages...
>

IMHO double-headed arrow looks pretty nice and whole idea is great. Very
big +1 for this feature

>
> On Mon, Jul 11, 2016 at 5:33 PM, Marco Pivetta  wrote:
> > Still interested: what's the actual added value of this sort of
operator?
> >
> > Marco Pivetta
> >
> > http://twitter.com/Ocramius
> >
> > http://ocramius.github.com/
> >
> > On 11 July 2016 at 17:28, Rowan Collins  wrote:
> >
> >> On 11/07/2016 16:15, Michael Morris wrote:
> >>
> >>> But for that to currently work setSomething must return $this.  A
cascade
> >>> operator would avoid this.  What about =>  ?
> >>>
> >>> $a->setSomething('here')=>setSomethingElse('there');
> >>>
> >>
> >> This will be ambiguous with array syntax, e.g.
> >>
> >> $foo = [ $a->foo() => bar() ]
> >>
> >> could be a call to $a->foo() for the key and to bar() for the value, or
> >> just a chain ending with the array value $a->bar().
> >>
> >> Naming things is hard. Inventing operators is harder. ;)
> >>
> >> Also note that it's the *first* call that needs a special operator, in
> >> order to discard the normal return and substitute the left-hand side,
> >> otherwise mixed chains become ambiguous and probably horrible to
implement
> >> in the engine:
> >>
> >> $foo->bar()->baz()=>bob() // what is $this inside bob() ?
> >>
> >>
> >>
> >> For this sort of chaining I'd propose, in addition to the cascade
operator,
> >>> the chain operator. This would work like the cascade operator except
that
> >>> the return of the function is implicitly the first parameter of the
next
> >>> argument in the chain. Something like this?
> >>>
> >>> $a->add(1, 2):>subtract(3):>add(4); // return 4.
> >>>
> >>
> >> This exact feature was proposed a couple of months ago by Sara Golemon.
> >> See https://wiki.php.net/rfc/pipe-operator and the accompanying
> >> discussion http://marc.info/?t=14619608891=4=2
> >>
> >> As far as I know, it's not been formally withdrawn, so might be
> >> resurrected in some for for 7.2. It might be interesting to see a
cascade
> >> operator at the same time, but some of the same concerns that came up
in
> >> that discussion will probably apply to any proposal.
> >>
> >> Regards,
> >> --
> >> Rowan Collins
> >> [IMSoP]
> >>
> >> --
> >> PHP Internals - PHP Runtime Development Mailing List
> >> To unsubscribe, visit: http://www.php.net/unsub.php
> >>
> >>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To 

Re: [PHP-DEV] [RFC][Vote] ReflectionType Improvements

[Aaron Piotrowski]

Hi Levi,

> On Jul 9, 2016, at 10:12 AM, Levi Morrison  wrote:
> 
> On Sat, Jul 9, 2016 at 8:16 AM, Aaron Piotrowski  > wrote:
>> 
>> 
>> Additionally, I propose adding a getName() method to ReflectionType that 
>> returns only the name of the type, regardless of nullability. Casting should 
>> not be required to get information from an object, but currently this is the 
>> only way to get the type name from ReflectionType. Most other reflection 
>> classes include a getName() method, this seems to have been an oversight.
> 
> This wasn't an oversight. If we add union or intersection types then
> not all types are named (for instance `ArrayAccess & Countable &
> Traversable` is not a named type). This is why it doesn't exist on the
> base ReflectionType.

Good point, then I agree getName() should be in an extending class as in the 
RFC.

> 
> I have surveyed some of the people who have voted no. Their reasons
> vary but based on these conversations it seems to me that by dropping
> ReflectionClassType and the associated autoloading mechanism that
> overall we'd be happier. I do agree with Aaron that at least *some*
> changes really need to go into 7.1. How do people feel about my
> proposal to just drop autoloading and `ReflectionClassType`?

This sounds reasonable to me.

Aaron Piotrowski

Re: [PHP-DEV] Cascade Operator (was Re: [PHP-DEV] Proposal for php7 class method return)

[Rasmus Schultz]

> what's the actual added value of this sort of operator?

The only direct value to the language is brevity - mere convenience.

But I think the biggest indirectly added value, is that this will
discourage people from the chainable methods anti-pattern - so this
has value to the community; those who write chainable methods can
stop, and those who want chainable methods can get a wider choice of
libraries that were previously too verbose in use for their taste.

> For this sort of chaining I'd propose, in addition to the cascade operator,
> the chain operator. This would work like the cascade operator except that
> the return of the function is implicitly the first parameter of the next
> argument in the chain

I don't like this idea, at all - I think we should aim for something
consistent with other languages. Per the Dart spec:

> A cascaded method invocation expression of the form e..suffix is equivalent 
> to the expression (t){t.suffix; return t;}(e).

In other words, the expression always evaluates as the object, which
is fine for most cases, e.g. for everything you're doing with
chainable methods today - which can't actually return any values,
since they return $this. Note that something like PSR-7's HTTP
immutable models are actually factory methods, e.g. use-cases not
applicable to the cascade operator.

The other marginal use case perhaps is cases where a builder of some
sort ends with a call to a factory method - this can be done without
adding a second operator, by using parens in a similar fashion to Dart
and others, e.g.:

$object = ($builder
->>setFoo(1)
->>setBar(2)
->>setBaz(3)
)->build();

Or obviously:

$builder
->>setFoo(1)
->>setBar(2)
->>setBaz(3);

$object = $builder->build();

Regarding syntax - I feel the natural choice, e.g. similar to "." vs
"..", would be a longer arrow --> but that's ambiguous. (decrement
operator, greater than operator)

The proposed |> operator looks horrible and is very awkward to type,
at least on both American and Danish keyboard - I use both. (it reads
like "or greater than" in my mind, so much so that glancing over
Sara's proposal earlier, I didn't even understand what it was.)

Would something like ->> be ambiguous as well? That's fairly close too
- a double-headed arrow, not unlike the double dots of other
languages...


On Mon, Jul 11, 2016 at 5:33 PM, Marco Pivetta  wrote:
> Still interested: what's the actual added value of this sort of operator?
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>
> On 11 July 2016 at 17:28, Rowan Collins  wrote:
>
>> On 11/07/2016 16:15, Michael Morris wrote:
>>
>>> But for that to currently work setSomething must return $this.  A cascade
>>> operator would avoid this.  What about =>  ?
>>>
>>> $a->setSomething('here')=>setSomethingElse('there');
>>>
>>
>> This will be ambiguous with array syntax, e.g.
>>
>> $foo = [ $a->foo() => bar() ]
>>
>> could be a call to $a->foo() for the key and to bar() for the value, or
>> just a chain ending with the array value $a->bar().
>>
>> Naming things is hard. Inventing operators is harder. ;)
>>
>> Also note that it's the *first* call that needs a special operator, in
>> order to discard the normal return and substitute the left-hand side,
>> otherwise mixed chains become ambiguous and probably horrible to implement
>> in the engine:
>>
>> $foo->bar()->baz()=>bob() // what is $this inside bob() ?
>>
>>
>>
>> For this sort of chaining I'd propose, in addition to the cascade operator,
>>> the chain operator. This would work like the cascade operator except that
>>> the return of the function is implicitly the first parameter of the next
>>> argument in the chain. Something like this?
>>>
>>> $a->add(1, 2):>subtract(3):>add(4); // return 4.
>>>
>>
>> This exact feature was proposed a couple of months ago by Sara Golemon.
>> See https://wiki.php.net/rfc/pipe-operator and the accompanying
>> discussion http://marc.info/?t=14619608891=4=2
>>
>> As far as I know, it's not been formally withdrawn, so might be
>> resurrected in some for for 7.2. It might be interesting to see a cascade
>> operator at the same time, but some of the same concerns that came up in
>> that discussion will probably apply to any proposal.
>>
>> Regards,
>> --
>> Rowan Collins
>> [IMSoP]
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Cascade Operator (was Re: [PHP-DEV] Proposal for php7 class method return)

[Rowan Collins]

On 11/07/2016 16:33, Marco Pivetta wrote:

Still interested: what's the actual added value of this sort of operator?


Arguably, the same value there is any syntax.

You could say that the -> operator is just a more readable form of 
overloaded function calls:


class Something { function bar(int $value); }
$foo->bar(42);

vs

function bar(@overload Something $this, int $value);
bar($foo, 42);

And, indeed, that all operators are just a more readable form of 
function calls.



Chaining syntax makes a certain style of programming easier. It doesn't 
allow you to do anything that you can't do without it, and the change is 
mostly cosmetic. Whether that's a good thing or bad thing depends 
whether you think that's a good style or not.


A bit of a non-answer, perhaps, but the question is pretty woolly too.

Regards,
--
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Cascade Operator (was Re: [PHP-DEV] Proposal for php7 class method return)

[Marco Pivetta]

Still interested: what's the actual added value of this sort of operator?

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

On 11 July 2016 at 17:28, Rowan Collins  wrote:

> On 11/07/2016 16:15, Michael Morris wrote:
>
>> But for that to currently work setSomething must return $this.  A cascade
>> operator would avoid this.  What about =>  ?
>>
>> $a->setSomething('here')=>setSomethingElse('there');
>>
>
> This will be ambiguous with array syntax, e.g.
>
> $foo = [ $a->foo() => bar() ]
>
> could be a call to $a->foo() for the key and to bar() for the value, or
> just a chain ending with the array value $a->bar().
>
> Naming things is hard. Inventing operators is harder. ;)
>
> Also note that it's the *first* call that needs a special operator, in
> order to discard the normal return and substitute the left-hand side,
> otherwise mixed chains become ambiguous and probably horrible to implement
> in the engine:
>
> $foo->bar()->baz()=>bob() // what is $this inside bob() ?
>
>
>
> For this sort of chaining I'd propose, in addition to the cascade operator,
>> the chain operator. This would work like the cascade operator except that
>> the return of the function is implicitly the first parameter of the next
>> argument in the chain. Something like this?
>>
>> $a->add(1, 2):>subtract(3):>add(4); // return 4.
>>
>
> This exact feature was proposed a couple of months ago by Sara Golemon.
> See https://wiki.php.net/rfc/pipe-operator and the accompanying
> discussion http://marc.info/?t=14619608891=4=2
>
> As far as I know, it's not been formally withdrawn, so might be
> resurrected in some for for 7.2. It might be interesting to see a cascade
> operator at the same time, but some of the same concerns that came up in
> that discussion will probably apply to any proposal.
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Cascade Operator (was Re: [PHP-DEV] Proposal for php7 class method return)

[Rowan Collins]

On 11/07/2016 16:15, Michael Morris wrote:

But for that to currently work setSomething must return $this.  A cascade
operator would avoid this.  What about =>  ?

$a->setSomething('here')=>setSomethingElse('there');


This will be ambiguous with array syntax, e.g.

$foo = [ $a->foo() => bar() ]

could be a call to $a->foo() for the key and to bar() for the value, or 
just a chain ending with the array value $a->bar().


Naming things is hard. Inventing operators is harder. ;)

Also note that it's the *first* call that needs a special operator, in 
order to discard the normal return and substitute the left-hand side, 
otherwise mixed chains become ambiguous and probably horrible to 
implement in the engine:


$foo->bar()->baz()=>bob() // what is $this inside bob() ?




For this sort of chaining I'd propose, in addition to the cascade operator,
the chain operator. This would work like the cascade operator except that
the return of the function is implicitly the first parameter of the next
argument in the chain. Something like this?

$a->add(1, 2):>subtract(3):>add(4); // return 4.


This exact feature was proposed a couple of months ago by Sara Golemon. 
See https://wiki.php.net/rfc/pipe-operator and the accompanying 
discussion http://marc.info/?t=14619608891=4=2


As far as I know, it's not been formally withdrawn, so might be 
resurrected in some for for 7.2. It might be interesting to see a 
cascade operator at the same time, but some of the same concerns that 
came up in that discussion will probably apply to any proposal.


Regards,
--
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Cascade Operator (was Re: [PHP-DEV] Proposal for php7 class method return)

[Michael Morris]

On Sun, Jul 10, 2016 at 6:34 AM, Rasmus Schultz  wrote:

>
> What you're really trying to accomplish is something like the ".."
> operator found in some other languages - this is known as the "cascade
> operator" in Dart, for example:
>
>
> http://news.dartlang.org/2012/02/method-cascades-in-dart-posted-by-gilad.html
>
> There are several problems with method-chaining - the biggest problem,
> as demonstrated by the cascade operator, is that this doesn't need to
> be a problem you solve for every class; it can be done systemically
> with a cascade operator, e.g. supported for every class, not just
> those where you weave in this requirement. Also, method chaining is
> inferior to a cascade operator, which would work not only for methods,
> but for properties as well. More over, a cascade operator would work
> for all existing libraries, whether the designer thought about
> cascading use of various features or not.
>
> In short, this shouldn't and doesn't need to be a problem every
> developer solves for each and every library - we can solve it for the
> language instead.
>
> In other words, it seems you're trying to address a problem that
> shouldn't exist in the first place, so that you can solve a recurring
> problem you should not have to solve at all.
>
> I would be much more interested in seeing a proposal for a cascade
> operator, which, in my opinion, addresses the real problem currently
> driving developers to use method-chaining - I can only view that as an
> unfortunate work-around.
>
> In my opinion, a cascade operator would move the language forward,
> while the addition of a magical type-hint acting as sugar for "return
> $this" merely solves a superficial problem - and propagates a bad
> practice.
>
>
This is a fascinating concept. There's a small gap to this implementation
which I think can be improved on, but still fascinating.

So we currently have -> for invocation of a method on an object.

$a->setSomething('here')->setSomethingElse('there');

But for that to currently work setSomething must return $this.  A cascade
operator would avoid this.  What about =>  ?

$a->setSomething('here')=>setSomethingElse('there');


This alone is pretty cool, but what if you have a method that returns
something you want to use as argument?  The old prototype.js library.
Consider the following

class A {
  public function add( $a, $b) {
return $a + b;
  }

  public function subtract( $a, $b) {
return $a - $b;
  }
}

For this sort of chaining I'd propose, in addition to the cascade operator,
the chain operator. This would work like the cascade operator except that
the return of the function is implicitly the first parameter of the next
argument in the chain. Something like this?

$a->add(1, 2):>subtract(3):>add(4); // return 4.

As can be seen above, I'm unsure of what the static method syntax should be.

[PHP-DEV] GOOD Benchmark Results for PHP Master 2016-07-11

[lp_benchmark_robot]

Results for project PHP master, build date 2016-07-11 06:28:58+03:00
commit: 5f6effe
previous commit:d77a8b0
revision date:  2016-07-10 15:15:34+02:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, 
stepping 2, LLC 45 MB
mem:128 GB
os: CentOS 7.1
kernel: Linux 3.10.0-229.4.2.el7.x86_64

Baseline results were generated using release php-7.0.0, with hash 60fffd2 from
2015-12-01 04:16:47+00:00

---
benchmark   relative   change since   change since  
current rev run
std_dev*   last run   baseline  
   with PGO
---
:-|   Wordpress 4.2.2 cgi -T1  0.08%  0.04%  0.35%  
  7.09%
:-|   Drupal 7.36 cgi -T1  0.20% -0.56% -1.19%  
  5.35%
:-|   MediaWiki 1.23.9 cgi -T5000  0.09% -0.41%  0.57%  
  3.93%
:-|   bench.php cgi -T100  0.02%  0.76% 32.33%  
 -6.19%
:-)  micro_bench.php cgi -T10  0.09%  4.33% 14.75%  
  1.60%
:-)  mandelbrot.php cgi -T100  0.01%  2.52% 31.62%  
 -0.04%
---

* Relative Standard Deviation (Standard Deviation/Average)

If this is not displayed properly please visit our results page here: 
http://languagesperformance.intel.com/good-benchmark-results-for-php-master-2016-07-11/

Note: Benchmark results for Wordpress, Drupal, MediaWiki are measured in
fetches/second while all others are measured in seconds.
More details on measurements methodology at: 
https://01.org/lp/documentation/php-environment-setup.

Subject Label Legend:
Attributes are determined based on the performance evolution of the workloads
compared to the previous measurement iteration.
NEUTRAL: performance did not change by more than 1% for any workload
GOOD: performance improved by more than 1% for at least one workload and there
is no regression greater than 1%
BAD: performance dropped by more than 1% for at least one workload and there is
no improvement greater than 1%
UGLY: performance improved by more than 1% for at least one workload and also
dropped by more than 1% for at least one workload


Our lab does a nightly source pull and build of the PHP project and measures
performance changes against the previous stable version and the previous nightly
measurement. This is provided as a service to the community so that quality
issues with current hardware can be identified quickly.

Intel technologies' features and benefits depend on system configuration and may
require enabled hardware, software or service activation. Performance varies
depending on system configuration.


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Proposal for php7 class method return

[Marco Pivetta]

Hi Jesse,

On 10 July 2016 at 14:31, Jesse Schalken  wrote:

> On Sun, Jul 10, 2016 at 8:34 PM, Rasmus Schultz 
> wrote:
>
> >
> > What you're really trying to accomplish is something like the ".."
> > operator found in some other languages - this is known as the "cascade
> > operator" in Dart, for example:
> >
> >
> >
> http://news.dartlang.org/2012/02/method-cascades-in-dart-posted-by-gilad.html
> >
> >
>
> While I was writing about an operator to set object properties in-line
> here: http://news.php.net/php.internals/93662 , I considered it would be
> easy to add method calls to the same syntax:
>
>
> return Blah::create(5) {
> prop1 = 'hello',
> prop2 = a_func(),
> setThing(9),
> setOtherThing(1),
> };
>
>
> which is in principle just an alternative syntax to as the cascade operator
> in Dart.
>
> I agree entirely that method chaining is just a verbose workaround for the
> lack of such a language feature. I've found a few problems with method
> chaining which this would resolve:
>
>1. The verbosity of adding "return $this;" to all your mutator methods
>(Daniel Ciochiu's issue).
>

`return $this;` is a fairly common anti-pattern. It can be useful in few
edge-cases, like immutable APIs (CoW) and DSL builders, but it's usually a
bad idea. I ranted extensively about this at
https://ocramius.github.io/blog/fluent-interfaces-are-evil/


>2. You can't return a value from a mutator method while also supporting
>method chaining. In theory mutator methods shouldn't need a return value
>(command-query separation) but in many cases they do, such as a setter
>which returns the previous value, a pop() method on a stack, or a
>delete($where) method returning the number of deleted records.
>3. It is often unclear whether a method being chained is returning the
>same object it was called on, a copy of the object, or an instance of a
>different class altogether. You can work around this with careful method
>naming and documentation ("with.." for new instance, "set.." for same
>instance etc), but language-level support eliminates this issue
> entirely.
>

Are you actually talking about a `$this` return-hint? That would indeed
solve some issues, by enforcing identity as part of the return type. Don't
think that there are scenarios where identity is required though, as it
would be useless (the hint would not serve any actual
behavioral/expressiveness improvement).

@Daniel: the fact that an implicit return is added to the opcodes for a
method that has a `self` hint seems useless/magic to me. It would basically
allow automatic fluent interfaces, enforcing something useless though,
since a fluent interface does not provide any actual usefulness per-se
(besides code-style preferences).


Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Re: [PHP-DEV] Request for wiki karma

[Niklas Keller]

2016-07-10 21:27 GMT+02:00 Charles R. Portwood II <
charlesportwoo...@erianna.com>:

> On Sun, Jul 10, 2016 at 12:36 AM, Scott Arciszewski 
> wrote:
>
> > Version 1.3 of the Argon2 spec alleviated my concerns.
> >
> > I never completed my patch, and the past couple of months have been
> > hectic. I can review the patch before it's merged if you want, but I
> still
> > don't have the free time to author an alternative.
> >
> > If accepted in 7.1, I believe it can be the new PASSWORD_DEFAULT in 7.3
> if
> > it remains the best option.
> >
> > Scott Arciszewski
> > Chief Development Officer
> > Paragon Initiative Enterprises 
> >
> > On Sun, Jul 10, 2016 at 1:24 AM, Pierre Joye 
> wrote:
> >
> >>
> >> On Jul 10, 2016 2:38 AM, "Charles R. Portwood II" <
> >> charlesportwoo...@erianna.com> wrote:
> >> >
> >> > Hello Internals,
> >> >
> >> > I'd like to improve the password_* functions by adding support for
> >> > Argon2[1], the winner of the Password Hasing Competition[2].
> >> >
> >> > I've previously implemented an extension[3] to handle this, however I
> >> > believe this would be better to have Argon2 implemented directly
> >> password_*
> >> > functions. I would handle implementation of this enhancement, and
> would
> >> > like to gather your feedback before formally proposing an RFC.
> >> >
> >> > My wiki username is: charlesportwoodii
> >> >
> >> > Thank you!
> >> > *Charles R. Portwood II*
> >> >
> >> > [1] 
> >> > [2] 
> >> > [3] 
> >>
> >> Hi Charles,
> >>
> >> Nice work already.
> >>
> >> I add Scott to this thread to be sure he reads. As far as I remember he
> >> has a patch too but there was concerns about having argon2 support at
> this
> >> stage because of the current state of argon2 specs (or something along
> this
> >> line).
> >>
> >> Let be sure that these concerns are solved before considering to include
> >> it as it means some bc risks later if the specs change.
> >>
> >> Cheers
> >> Pierre
> >>
> >
> >
> Thanks for your feedback everyone (and for granting wiki access)!
>
> This implementation would be against the version 1.3 of the Argon2
> reference library. As Scott mentioned, this proposal would be for inclusion
> on 7.1, and then made PASSWORD_DEFAULT in 7.3 per the password_hash RFC,
> assuming better option does not arise.
>
> I'll provide an RFC within the coming days which will outline everything in
> detail.
>
> Thanks again,
>
> *Charles R. Portwood II*


Hi Charles,

it will probably have to target 7.2 as 7.1 has feature freeze in less then
two weeks IIRC.

Regards, Niklas