Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

[Theodore Brown]

On Mon, Oct 7, 2019 at 2:50 AM Nikita Popov  wrote:

> On Fri, Oct 4, 2019 at 5:45 PM Mark Randall  wrote:
> 
> > Hi Internals,
> >
> > I put forward the following RFC "Deprecate Backtick Operator (V2)" for
> > discussion.
> >
> > https://wiki.php.net/rfc/deprecate-backtick-operator-v2
> >
> > I believe it is at least worth a discussion as to the pros and cons of
> > deprecating this functionality, especially in light of the existence of
> > better described and more well-known functions exhibiting identical
> > behaviour.
> >
> > This RFC only covers the issuing a deprecation notice, and its complete
> > removal would be contained within a separate RFC.
> >
> 
> Usage of backtick operator in packagist top 2k packages:
> https://gist.github.com/nikic/7b0afaf4d8b1a1087cdb61cd1e776594
> There are 72 occurrences including duplicates.
> 
> Make of that whatever you will :)


I did some further analysis on the output of Nikita's script.
Ignoring the duplicate WordPress package, all the occurrences
are in just 21 unique projects.

In 8 of these, the backtick uses are exclusively in test files or other
scripts not part of the library source code. Then there are 11 packages
with one or two uses each, and only 2 packages with more than two occurrences.

Raw numbers: https://gist.github.com/theodorejb/584f2a1e27e93fb5da2d9b0e8e7a0d34

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

Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

[Olumide Samson]

On Mon, Oct 7, 2019, 9:20 PM Claude Pache  wrote:

>
> > Le 7 oct. 2019 à 22:06, Olumide Samson  a écrit :
> >
> >
> > What's the goal of PHP?
>
> One important goal is (like many programming languages) to get work done.
>
> —Claude
>
I disagree, coz this seems to be a goal cooked up by you(even if I might
believe in the general idea of that goal, I still can't believe it until I
see where it was outlined).

Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

[Claude Pache]

> Le 7 oct. 2019 à 22:06, Olumide Samson  a écrit :
> 
> 
> What's the goal of PHP?

One important goal is (like many programming languages) to get work done. 

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

Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

[Olumide Samson]

On Mon, Oct 7, 2019, 7:53 PM Stanislav Malyshev  wrote:

> Hi!
>
> > That is the purpose of the eventual vote, is it not? To allow the
> > community to make that determination.
>
> Not exactly - there should be a good reason before the RFC comes to a
> vote. If you're not sure there's a VERY good reason, there shouldn't be
> the RFC about it at all, at least not in voting phase. RFC process
> shouldn't be just "let's throw it against the wall and see if anything
> sticks", it should be used responsibly.
>
> > Regardless of the outcome of this specific RFC, I am of the firm belief
> > that it's important to be able to re-visit past choices every now and
> > then. That applies to most things, not just PHP.
>
> In abstract, this a banality, yes, it is important, sometimes. In
> specific, I've seen a torrent of BC-breaking proposals lately that seem
> to have no good reason except for removing stuff because... I'm not even
> sure because of what, most of it seems to be vague stuff like
> "unintuitive" and "you can do it in other way". I think effort spent on
> breaking BC without a VERY good reason is a wasted effort. Having as
> little syntax constructs and functions as absolutely possible has never
> been the goal of PHP, and I am surprised why it is in fashion now.
> --
> Stas Malyshev
> smalys...@gmail.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php


What's the goal of PHP?

Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

[Stanislav Malyshev]

Hi!

> That is the purpose of the eventual vote, is it not? To allow the
> community to make that determination.

Not exactly - there should be a good reason before the RFC comes to a
vote. If you're not sure there's a VERY good reason, there shouldn't be
the RFC about it at all, at least not in voting phase. RFC process
shouldn't be just "let's throw it against the wall and see if anything
sticks", it should be used responsibly.

> Regardless of the outcome of this specific RFC, I am of the firm belief
> that it's important to be able to re-visit past choices every now and
> then. That applies to most things, not just PHP.

In abstract, this a banality, yes, it is important, sometimes. In
specific, I've seen a torrent of BC-breaking proposals lately that seem
to have no good reason except for removing stuff because... I'm not even
sure because of what, most of it seems to be vague stuff like
"unintuitive" and "you can do it in other way". I think effort spent on
breaking BC without a VERY good reason is a wasted effort. Having as
little syntax constructs and functions as absolutely possible has never
been the goal of PHP, and I am surprised why it is in fashion now.
-- 
Stas Malyshev
smalys...@gmail.com

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

RE: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

[Reinis Rozitis]

> -Original Message-
> From: Mark Randall [mailto:marand...@php.net]
> 
> On 06/10/2019 14:18, Reinis Rozitis wrote:
> > Since `` are used for literal strings (for poorly chosen reserved words as 
> > field,
> table names (which happens from time to time)) in MySQL (multiline) queries I
> doubt there is a simple way to distinguish and replace everything to exec().
> 
> Hi,
> 
> As the RFC states, there are already widely used tools available which can do
> this reliably:
> 
> https://github.com/FriendsOfPHP/PHP-CS-Fixer
> backtick_to_shell_exec
> 
> --
> Mark Randall

Sure,
it was only a comment about "without huge Regex searches" from previous poster 
while the tool has those "tricky" parts 
https://github.com/FriendsOfPHP/PHP-CS-Fixer/blob/2.15/src/Fixer/Alias/BacktickToShellExecFixer.php
(hence the help message and comments inside code)

rr

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

Re: [PHP-DEV] Re: [VOTE] Object Initializer

[Michał Brzuchalski]

Hi Marco,

pon., 7 paź 2019 o 13:24 Marco Pivetta  napisał(a):

> Hey Michal,
>
> Overall, I like the idea of simplifying constructors. I downvoted the RFC
> because:
>
>  * I don't like/want co-existence of ctor and initializer
>  * `__set` interactions seem to also be a lot of non-trivial added
> complexity.
>
> If this was a short-hand for a constructor replacement (exposed in the same
> way downstream and in reflection) I'd totally be for it, but as it is it
> blurs the entire class definition by a lot, making things very difficult to
> anything reflection-ish based.
>

Thank you for your feedback.

Cheers,
Michał Brzuchalski

Re: [PHP-DEV] Re: [VOTE] Object Initializer

[Marco Pivetta]

Hey Michal,

Overall, I like the idea of simplifying constructors. I downvoted the RFC
because:

 * I don't like/want co-existence of ctor and initializer
 * `__set` interactions seem to also be a lot of non-trivial added
complexity.

If this was a short-hand for a constructor replacement (exposed in the same
way downstream and in reflection) I'd totally be for it, but as it is it
blurs the entire class definition by a lot, making things very difficult to
anything reflection-ish based.

On Mon, Oct 7, 2019, 13:18 Michał Brzuchalski 
wrote:

> Hi all,
>
> A follow-up note.
> There is no implementation of a patch yet.
>
> BR,
> Michał Brzuchalski
>
> pon., 7 paź 2019 o 13:00 Michał Brzuchalski 
> napisał(a):
>
> > Hi all,
> >
> > the discussion period was long and discussion I think quite
> comprehensive.
> >
> > The RFC is at https://wiki.php.net/rfc/object-initializer and is up for
> > voting now.
> > The voting will take 2 weeks from 11:00 UTC 7th till 11:00 UTC 21st of
> > October 2019.
> >
> > BR,
> > Michał Brzuchalski
> >
>
>
> --
> regards / pozdrawiam,
> --
> Michał Brzuchalski
> about.me/brzuchal
> brzuchalski.com
>

[PHP-DEV] Re: [VOTE] Object Initializer

[Michał Brzuchalski]

Hi all,

A follow-up note.
There is no implementation of a patch yet.

BR,
Michał Brzuchalski

pon., 7 paź 2019 o 13:00 Michał Brzuchalski 
napisał(a):

> Hi all,
>
> the discussion period was long and discussion I think quite comprehensive.
>
> The RFC is at https://wiki.php.net/rfc/object-initializer and is up for
> voting now.
> The voting will take 2 weeks from 11:00 UTC 7th till 11:00 UTC 21st of
> October 2019.
>
> BR,
> Michał Brzuchalski
>


-- 
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

[PHP-DEV] [VOTE] Object Initializer

[Michał Brzuchalski]

Hi all,

the discussion period was long and discussion I think quite comprehensive.

The RFC is at https://wiki.php.net/rfc/object-initializer and is up for
voting now.
The voting will take 2 weeks from 11:00 UTC 7th till 11:00 UTC 21st of
October 2019.

BR,
Michał Brzuchalski

[PHP-DEV] Reverting "Link executable files using non PIC object files"

[Dmitry Stogov]

Hi,

There were a number of build problems caused by my PR 
https://github.com/php/php-src/pull/4678

Today I got another report from Remi 
https://github.com/php/php-src/commit/f633c347574c0d814050b4bf2493e0cac6a5988c
Although, the patch makes visible performance improvement, it's probably better 
to revert it and all the related fixes for PHP-7.4.

Thanks. Dmitry.

[PHP-DEV] Re: [RFC] Object Initializer

[Michał Brzuchalski]

Hi all,

the discussion period was long and discussion I think quite comprehensive.

I'd like to open the RFC up for a voting today at 11:00 UTC. The voting
will take from 11:00 UTC 7th till 11:00 UTC 21st of October 2019.

BR,
Michał Brzuchalski

czw., 12 wrz 2019 o 16:00 Michał Brzuchalski 
napisał(a):

> Hi internals,
>
> I'd like to open discussion about RFC: Object Initializer.
>
> This proposal reduces boilerplate of object instantiation and properties
> initialization in case of classes without required constructor arguments as
> a single expression with initializer block.
>
> https://wiki.php.net/rfc/object-initializer
>
> I appreciate any feedback you all can provide.
>
> Thanks,
> --
> Michał Brzuchalski
> brzuc...@php.net
>

Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

[Mark Randall]

On 07/10/2019 07:22, Stanislav Malyshev wrote:

I personally thought we had thom - no removing things unless there's a
very good reason to. 


Hi Stanislav,

It has yet to be determined if there's a consensus on if the arguments 
given in favour of deprecation represent a good enough reason for the BC 
change.


That is the purpose of the eventual vote, is it not? To allow the 
community to make that determination.


Regardless of the outcome of this specific RFC, I am of the firm belief 
that it's important to be able to re-visit past choices every now and 
then. That applies to most things, not just PHP.


--
Mark Randall

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

Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

[Nikita Popov]

On Fri, Oct 4, 2019 at 5:45 PM Mark Randall  wrote:

> Hi Internals,
>
> I put forward the following RFC "Deprecate Backtick Operator (V2)" for
> discussion.
>
> https://wiki.php.net/rfc/deprecate-backtick-operator-v2
>
> I believe it is at least worth a discussion as to the pros and cons of
> deprecating this functionality, especially in light of the existence of
> better described and more well-known functions exhibiting identical
> behaviour.
>
> This RFC only covers the issuing a deprecation notice, and its complete
> removal would be contained within a separate RFC.
>

Usage of backtick operator in packagist top 2k packages:
https://gist.github.com/nikic/7b0afaf4d8b1a1087cdb61cd1e776594
There are 72 occurrences including duplicates.

Make of that whatever you will :)

Nikita

Re: [PHP-DEV] [RFC] Object Initializer

[Michał Brzuchalski]

Hi Arvids,

sorry for the late response, I've been busy recently.

wt., 17 wrz 2019 o 13:08 Arvids Godjuks 
napisał(a):

>
> I've have been keeping up with the thread and at this point, I do somewhat
> agree with people that maybe the RFC should go into V2 version development.
> It really seems like the scope of the RFC is just too small for the feature
> and it might be a good idea to expand it a bit.
>

I'm gonna let it go as it currently is, there's still time before PHP 8.0
for improvements.
IMO with all the goods like list of properties to set and restriction which
forces to properly initialize object instance with all required fields is
enough.


> Also, I have this question - is there any performance to be gained here?
> Cause right now object hydration is an issue and is somewhat slow. Can it
> be optimised?
> Also, usually I don't really want properties to be public (aka writeable),
> so that means `private/protected` and I need to use the methods to set the
> properties or reflection. I might have missed or don't remember it, but I
> don't think I saw a discussion about that use-case. Value object, DTO's -
> all have a big use case for it.
>

This feature has no implementation yet so won't speak out about performance
and optimisation now.
Declaring classes with private/protected fields doesn't mean you cannot to
object initialization using object initializer, you can do this from class
inner scope exactly the same way as you're able to access them from class
inner scope now.
This feature may not be a cure for all diseases, but I believe is the right
to reduce noise and boilerplate when instantiating and initializing simple
objects with type restrictions and ensures valid object state every time
it's used.

BR,
Michał Brzuchalski