Re: [PHP-DEV] Re: PHP 7.0.0 final has been released!

[Daniel Persson]

I would also like to thank all participants for a great work on this new
version. Just as a testament about how much better this version is:

When we recently discussed what framework if any to use for data
manipulation we did benchmarks for both PHP5 and PHP7.
The test differed a lot in PHP5. All from 0.3 seconds up to 3 seconds.

But when we did the same test in PHP7 no framework required more than 0.5
seconds to complete the benchmarks. And pure PDO calls went from 0.3 to
0.21 seconds.

We're already looking at a plan to put PHP7 in our production environments.

Looking forward to a bright future for the project.

And again, thanks.

On Thu, Dec 3, 2015 at 10:38 PM, Ryan Pallas  wrote:

> On Thu, Dec 3, 2015 at 1:59 PM, Jan Ehrhardt  wrote:
>
> > a...@php.net in php.internals (Thu, 3 Dec 2015 21:46:00 +0100):
> > >Congratulations everyone to this spectacular day for the PHP world!
> > >Grateful thanks to all the contributors and supporters!
> >
> >
> I want to congratulate everyone for this and also to thank everyone
> involved for such a great improvement to the language. Everyone in
> internals should be proud of what they have achieved, as we the end user
> are going to reap great benefits! I and many others are very grateful for
> all your hard work!
>

Re: [PHP-DEV] Immutable modifier

[Daniel Persson]

Any differance from the final keyword?

http://php.net/manual/en/language.oop5.final.php

On Mon, Nov 16, 2015 at 10:15 AM, Chris Riley  wrote:

> Hi,
>
> There has been a lot of interest recently (eg psr-7) in immutable data. I'm
> considering putting an RFC together to add language support for immutables:
>
> immutable class Foo {
> public $bar;
> public function __construct($bar) {
> $this->bar = $bar;
> }
> }
>
> Immutable on a class declaration makes all (maybe only public?) properties
> of the class immutable after construct; assigning to a property would
> result in a Fatal error.
>
> class Foo {
> public $bar;
> immutable public $baz;
> }
>
> Immutable on a property makes the property immutable once it takes on a
> none null value. Attempts to modify the property after this results in a
> fatal error.
>
> Any thoughts?
> ~C
>

Re: [PHP-DEV] Re: [RFC][DISCUSSION] Revisit trailing commas in function arguments

[Daniel Persson]

I'll echo Andrea remarks,
-1, sorry.

On Thu, Oct 15, 2015, 01:25 Andrea Faulds  wrote:

> Hey Sammy,
>
> Sammy Kaye Powers wrote:
> > I'd like to open a discussion on the RFC to allow trailing commas in
> > function arguments.
> >
> > https://wiki.php.net/rfc/revisit-trailing-comma-function-args
> >
> > Discuss! :)
>
> Hmm. I'm not sure if this is a good idea. For arrays, trailing commas
> make perfect sense: arrays are very often written over multiple lines,
> where trailing commas look pretty, and it's likely new elements will be
> added or old elements removed, justifying the trailing comma for cleaner
> diffs and less pain when editing the source.
>
> But for functions? Most function calls are just a single line. Most
> function declarations, too. And even when they are multi-line, you're
> not going to be adding a new argument or parameter, respectively, very
> often. Since these additions aren't very common, you'd need to use
> trailing commas everywhere (yuck) to get any benefit, because you
> probably can't predict which instances you're going to change soon.
>
> To me this looks like something that adds another big stylistic
> difference to disagree on, and adds potential ugliness (`foo($bar,);`)
> for very limited gain.
>
> So, my intial reaction would be a -1, sorry.
>
> Thanks.
> --
> Andrea Faulds
> http://ajf.me/
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] [DRAFT]: Consistent callables

[Daniel Persson]

Hi Dan.

Had this email in the "need-to-read" pile for over a week and finally got
the time to go though the RFC.

Seems like this is something that we need to address. Inconsistencies are
never good.

The only thing I want to point out is that is_callable as well as
method_exists don't state in the manual that the functions or methods
referred is visible.
To make this function implied I think the manual should be updated to state
it.

For instance

public class A {
private function foo() {}
}

method_exists(new A(), "foo") is technically true.
The method exist but is not visible from your context. For instance when
you use reflection you might want to find any method that exists? Or should
that be handled by the pure reflection API? Either way I think the manual
needs to state this clearly.

Best regards
Daniel

On Tue, Sep 29, 2015 at 4:25 PM, Dan Ackroyd  wrote:

> Hello internals,
>
> Here is a draft RFC to make the callable type in PHP be consistent and
> have much fewer surprises.
>
> https://wiki.php.net/rfc/consistent_callables
>
> This RFC is probably not ready for the formal discussion that is held
> before a vote on it can be held as there may be some more details of
> what changes are necessary lurking, waiting to be found, in the PHP
> source code. However I would like to gather feedback about the
> likelihood of the RFC passing, as implementing a patch for this RFC is
> likely to be a significant amount of work.
>
> And yes most of this RFC targets PHP 8 with only small parts for 7.1.
> I realise that it is easy to think that it's a bit early to start
> thinking about that before 7 is out the door, but as there was a
> stampede of RFCs for PHP 7, I think the earlier RFCs can be discussed
> the better. Depending on the feedback, I imagine I would put this RFC
> up for a formal discussion and vote early in the new year.
>
> cheers
> Dan
> Ack
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Suggestion: Adding PUT, PATCH and DELETE

[Daniel Persson]

I've read some of the earlier discussion (not all, require sleep will read
more tomorrow).

To be clear I don't want to start a naming discussion again. If we have a
new name for $_POST or not isn't the main focus of this PR.

I want to allow PUT, PATCH and DELETE and handle them the same way as POST
so we get populated globals with data we could later filter and use.

Most of the frameworks work around this limitation in the core so I thought
it might be in place to suggest we allow these request methods.

On Mon, Sep 14, 2015 at 11:38 PM, Ryan Pallas <derokor...@gmail.com> wrote:

>
>
> On Mon, Sep 14, 2015 at 3:22 PM, Daniel Persson <mailto.wo...@gmail.com>
> wrote:
>
>> Hi.
>>
>> I've not been a member for too long so I might have missed if this have
>> been discussed earlier.
>>
>> But I've created a small PR to the basic request handling to support PUT,
>> PATCH and DELETE.
>>
>> https://github.com/php/php-src/pull/1519
>>
>> Summary:
>>
>> Added support for request methods with the smallest change possible.
>> History:
>>
>> HTTP 1.0 had only support for GET, POST and HEAD.
>> In June of 1999 HTTP 1.1 added the verbs PUT and DELETE and later in 2010
>> RFC5789 (https://tools.ietf.org/html/rfc5789) added PATCH.
>> Pull request explaination:
>>
>> In this pull request I try to add put, patch and delete with changing as
>> few functions as possible. I simply handle the new verbs as POST. As
>> defined in HTTP 1.1 they are similar in input data requirements and differ
>> only in usage.
>>
>
> +1 from me, would love to see the verbs supported more fully. (though my
> approval means quite literally nothing). How does this affect something
> like the ini settings for variable order? IE. does GPC change from GET ->
> POST -> COOKIE to GET -> PARSED_INPUT -> COOKIE? Since only a single verb
> is available for any single request, this makes the most sense for me.
>
>
>>
>> More work I could do is add new globals for $_PUT, $_PATCH and $_DELETE
>> but
>> I think this might be more confusing. Or we could move from $_POST to a
>> new
>> global not tied to a verb. Example $_PARSED_INPUT
>
>
> As for having a new $_PARSED_INPUT, I'm not sure I like this for 2 reasons
> a) the name is 2 words, all other super globals are single words (unless
> there's one I do not know of) and b) It feels like too long a name, sure in
> an IDE it will auto-complete for us, but for quick edits in vim for
> example, this name would suck. But my only problem with it is on a name
> level, about about just $_INPUT or does this seem to conflict with
> $_REQUEST which holds multiple super globals worth of data already.
>

[PHP-DEV] Suggestion: Adding PUT, PATCH and DELETE

[Daniel Persson]

Hi.

I've not been a member for too long so I might have missed if this have
been discussed earlier.

But I've created a small PR to the basic request handling to support PUT,
PATCH and DELETE.

https://github.com/php/php-src/pull/1519

Summary:

Added support for request methods with the smallest change possible.
History:

HTTP 1.0 had only support for GET, POST and HEAD.
In June of 1999 HTTP 1.1 added the verbs PUT and DELETE and later in 2010
RFC5789 (https://tools.ietf.org/html/rfc5789) added PATCH.
Pull request explaination:

In this pull request I try to add put, patch and delete with changing as
few functions as possible. I simply handle the new verbs as POST. As
defined in HTTP 1.1 they are similar in input data requirements and differ
only in usage.

More work I could do is add new globals for $_PUT, $_PATCH and $_DELETE but
I think this might be more confusing. Or we could move from $_POST to a new
global not tied to a verb. Example $_PARSED_INPUT

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

[Daniel Persson]

> Depends how you define simplicity. Because $a ~> $b ~> $c ~> $d is
> IMHO more simple than ($a) ~> ((($b) ~> (($c) ~> $d($foo))) - which is
> a result of the combination of amendments #2 and #3. I honestly do not
> know if I wrote the parenthesis right now or not (probably not),
> because there's simply just too many of them.

Might be a good place to suggest refactoring?
Removing a semantics because when you try to write too dense code it's hard
to read.
The same goes with an one line if assignments.

$a = ( [some really big expression] ) ? $b : $c;

Could be really hard to read but then you look into refactoring that code.

Might be my inexperience with closures but when do you chain 3 of them?

Best regards
Daniel


On Fri, Sep 4, 2015 at 9:43 AM, Pavel Kouřil  wrote:

> On Fri, Sep 4, 2015 at 8:57 AM, Peter Lind  wrote:
> > On 4 September 2015 at 08:44, Pavel Kouřil  wrote:
> >
> > You're arguing that, subjectively, to you - parentheses make things
> harder
> > to read. For others they clarify things.
> > It should be obvious to everyone that this particular path of the
> discussion
> > has about as much merit as tabs vs spaces.
>
> Sure, it is subjective - but what isn't?
>
> > That being the case, I would argue for consistency and simplicity. If you
> > need parentheses for other variants of this, require parentheses all the
> way
> > through. It will be simpler to learn and trip fewer people up.
>
> Depends how you define simplicity. Because $a ~> $b ~> $c ~> $d is
> IMHO more simple than ($a) ~> ((($b) ~> (($c) ~> $d($foo))) - which is
> a result of the combination of amendments #2 and #3. I honestly do not
> know if I wrote the parenthesis right now or not (probably not),
> because there's simply just too many of them.
>
> Sure, parenthesis can help people understand things, but I'd say that
> at the same time, too many of them can be a problem as well (as the
> fun name for LISP - "lost in stupid parenthesis" - suggests).
>
> > Just think, if whoever constructed the if conditional hadnt thought "hey,
> > let's be clever and save some keystrokes by making the curlies optional
> in
> > some cases" we wouldn't have the multitude of bugs and security holes we
> > know to exist, we wouldn't have to warn the young'uns against improper
> use
> > of if, we wouldn't have to write codesniffer rules against single line
> ifs,
> > etc, etc.
> >
> > Any argument to the effect of "let's be clever" or "it'll save some
> > keystrokes" is void. Period.
>
> This is not about saving characters, it's about not overcomplicating
> things.
>
> >
> > Regards
> > Peter
> >
>
> Regards
> PK
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>