Re: [PHP-DEV] Deprecate short_open_tag ini directive? PHP internals
>If you want to go further, dropping the PHP tag altogether would be nice,
since it would prevent context switching between PHP/HTML/JS/whatever.
>That would force Wordpress to update their whole
code base. >:{)>
I wholeheartedly support this initiative but I do not see it going through
without a lot of resistance. Using PHP itself as a templating engine is
part of what makes it so "newbie friendly".
Re: [PHP-DEV] Parameter skipping
The problem I see with this approach is that a keyword for skipping parameters would really just be a stopgap solution until something like Named Parameters can be added. Is it really appropriate to add a feature that only serves a temporary purpose? On Sat, Apr 6, 2019 at 5:15 PM Craig Duncan wrote: > Hi all, > > After starting to use https://wiki.php.net/rfc/json_throw_on_error in PHP > 7.3 I've encountered the annoying issue of having to pass the $depth > parameter as 512 every time I want json_decode() to throw. > > After doing this a few times I remembered the parameter skipping RFC that > Stas proposed a few years ago: https://wiki.php.net/rfc/skipparams > > I've re-read the previous discussion and it seems to me there were two > common arguments against: > * Just design better APIs > * Named parameters would be better > > Nobody has been able to crack named parameters (and it doesn't seem likely > anytime soon), and as we've seen from the JSON example above it's not > always as simple as having better APIs, so I wanted to see whether people > would be willing to support the *default* keyword for optional parameters > now. > > Thanks, > Craig >
Re: [PHP-DEV] Parameter skipping
>In order to use named parameters, somebody needs to have declared what those names are, and made them a stable API. If they're automatically supported on existing functions, the author might not intend them to be used, or even realise they can, so not keep them stable (I tend to think of parameter names as local, not contractual). Wouldn't using the name of the variable that is already used for its function signature work perfectly fine for this? This is how IDEs already hint for function call completion. On Sun, Apr 7, 2019 at 6:26 AM Rowan Collins wrote: > On 7 April 2019 06:00:53 BST, CHU Zhaowei wrote: > >The [named parameters](https://wiki.php.net/rfc/named_params) was > >proposed in 2013. Does the problems which stopped us before still exist > >in 2019? Since we all agree named parameter should be a better > >solution, why not take a look at it first? > > I'm not 100% convinced named parameters are the solution to this problem, > in all cases. > > In order to use named parameters, somebody needs to have declared what > those names are, and made them a stable API. If they're automatically > supported on existing functions, the author might not intend them to be > used, or even realise they can, so not keep them stable (I tend to think of > parameter names as local, not contractual). > > To use a default-skipping keyword, you need no extra promise than that > already made, namely that the default for any parameter is a valid value > for that parameter. > > Regards, > > -- > Rowan Collins > [IMSoP] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] Changing fundamental language behaviors
> While I realize my email is unpleasant for many to read, it's in the context of an RFC that attempts to do something that is strictly inappropriate and out of the question. Stating the fact, that the RFC process was never meant to allow this to be done, is a statement of fact. [...] > There won't be such processes either. These behaviors are here to stay. We can tweak them, we can augment them - we do not get to deprecate or radically change them. [...] > But those who dream of simply changing PHP into a stricter language step by step should understand that this is simply not going to be happen. Not now, not ever. Zeev, "strictly inappropriate and out of the question" seems like a statement of opinion to me. While I personally agree with your standpoint on changing this fundamental behavior, your response here seems out of left field. Furthermore, statements like "we do not get to deprecate or radically change them" and "this is simply not going to happen" are a wholly inappropriate response to *any* effort. I respect your vast contributions to the language and your (usually) level-headed stances on this mailing list, but you are not the grand czar of PHP and I don't believe that hard line is yours to make. Declaring such a thing reads to me like a spit in the face of everyone who contributes to the language and to the concept of a community-driven open source project to begin with. Over the past few years the movement to push PHP into more modern concepts has explosively grown in popularity and your resistance to the more rapid and drastic portions of it is understandable, if nothing else. However, using your bully pulpit to insist that things you don't like can't be done leaves a very sour taste in my mouth. If such limits exist, they should be clear and codified - not something that exists in the mind of you and whoever else only to be brought up when someone wants to breach them. On Thu, Sep 12, 2019 at 11:11 AM Zeev Suraski wrote: > > > > -Original Message- > > From: Marco Pivetta > > Sent: Thursday, September 12, 2019 5:59 PM > > To: Zeev Suraski > > Cc: PHP Internals List > > Subject: Re: [PHP-DEV] Changing fundamental language behaviors > > > > If you want to have an authoritative say on what the RFC process is for > or not, > > please start a new RFC about it: your mail is just straight out > inappropriate. > > No Marco. The RFC process wasn't meant to deal with who has authoritative > say any more than it was meant to deal with changing fundamental behaviors > in PHP. The fact we got used to putting everything to a vote doesn't mean > that it can work for anything and everything. > > While I realize my email is unpleasant for many to read, it's in the > context of an RFC that attempts to do something that is strictly > inappropriate and out of the question. Stating the fact, that the RFC > process was never meant to allow this to be done, is a statement of fact. > > I *hate* to be in the position to be the one who has to point it out and > stick to it. I know how much fire that's going to draw and I know I'd hate > every second of it. But it is what it is. > > There are no processes to make fundamental non-opt-in language changes in > PHP. There won't be such processes either. These behaviors are here to > stay. We can tweak them, we can augment them - we do not get to deprecate > or radically change them. > > We can (and I believe should) augment them with alternative, stricter > opt-in behaviors. But those who dream of simply changing PHP into a > stricter language step by step should understand that this is simply not > going to be happen. Not now, not ever. > > Zeev > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax to use short hand arrays
> I have already told you that the output of this function was never meant > for human consumption. > It was originally added to aid in caching of larger complicated data > structure through the likes of apc's opcode cache. It is sometimes used for human consumption now, though. For example, my team often uses it to generate database seeders from staging environments. With respect, I don't think "I didn't intend this to be used in the way it is now used" is a compelling argument against improving something, rather it's an argument *for* improvement in my eyes. Other arguments here not withstanding. On Mon, Mar 30, 2020 at 5:45 PM Derick Rethans wrote: > On Mon, 30 Mar 2020, Sherif Ramadan wrote: > > > Given that code is meant for human consumption > > I have already told you that the output of this function was never meant > for human consumption. > > It was originally added to aid in caching of larger complicated data > structure through the likes of apc's opcode cache. > > cheers, > Derick > > -- > PHP 7.4 Release Manager > Host of PHP Internals News: https://phpinternals.news > Like Xdebug? Consider supporting me: https://xdebug.org/support > https://derickrethans.nl | https://xdebug.org | https://dram.io > twitter: @derickr and @xdebug > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] 回复: [PHP-DEV] [rfc:direct-execution-opcode] Whether need __FILE__ the value of the file to replace the compiled opcode file path
I'm not 100% certain but I believe what chopins is proposing is the ability to require()/include() files generated by opcache, without including the .php file. The reference to __FILE__ is I believe a warning to using relative paths, since the compiled opcode file would be in a different location? On Thu, Dec 10, 2020 at 10:52 AM Sara Golemon wrote: > On Thu, Dec 10, 2020 at 8:40 AM €– ”k”k wrote: > > > Hi, Aleksander Machniak: > > which part is more difficult to read? Can you tell me? > > > > > All of it. > > I'm sorry, but I have absolutely no idea what you're trying to propose > here. Something about __FILE__ not being the right value in certain > circumstances because of something about opcache. > > -Sara >
