Re: [PHP-DEV] [RFC] Reclassifying engine warnings
On 28 August 2019 18:45:18 BST, Matthew Brown wrote: >Kicking a house is a poor analogy IMO - most people don’t upgrade a >major >language version without first verifying that their code still works in >the >new version. Probably. Most analogies fall down pretty quickly. I just feel like some of the messages on this thread about technical debt are taking great glee in kicking other people's code, rather than offering to help fix it. Let's talk about how to make this change successful. Let's talk about what tools there are, and what their strengths and limitations are. Let's talk about making people's lives easier now, not punishing them for past mistakes. Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
On 28 August 2019 17:53:55 BST, Matthew Brown wrote: >It's not breaking all the things - it's breaking code that should have >been broken already, but somehow wasn't. It's still breaking it though. If you realise that a house is built badly and could be destroyed by a well-aimed kick, you could just give it a kick and say "ah well, not my fault"; or you could warn the owners, offer help in fixing it, and understand that they might be too busy to do it right away. I don't see why it needs to be such a big deal to ask if this is something we actually need to kick, right now. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
On 28 August 2019 17:45:50 BST, Marco Pivetta wrote: >The point is that "some organisations do X" is always used as an excuse >for >turning language design mistakes into BC boundaries. No. Things that break compatibility are compatibility breaks. It doesn't matter if they were mistakes or fashions, if code will break, it will break. We can't change that by arguing about workflows and tools. Our job is to decide if and how to make those breaks. So, firstly, we need to agree that their is value to this particular break. I think there probably is, but people may have different opinions. Secondly, we need to think of a sensible way to introduce it. Is it responsible to put a note in an upgrading page and hope everyone spots it? Is there a way we can flag it more loudly? What is the best time frame to roll it out? Is there a way those who want to get it earlier can do so? Does that sound reasonable? Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
On 28 August 2019 16:05:13 BST, Marco Pivetta wrote: >A week for 700KLOC is *impressively low*. >Many organisations spend more time on *deciding* whether to upgrade a >patch >version of a dependency, and the tooling that vimeo has provided to >detect >these issues is technically impressive, and very much usable by other >orgs >too. I literally have no idea what to take from that response. Some organisations are slow, some have cool workflows, so let's break all the things? Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
On 28 August 2019 15:22:22 BST, Matthew Brown wrote: >Looking at our notice logs, I estimate (fairly roughly) that it would >require about a week's worth of my time to fix these issues I honestly thought you were posting that as an argument against. A week of resource (plus the accompanying QA impact etc) is a significant investment for many organisations. That's why it has the potential to delay adoption of a new version, and why a long lead-in via deprecation or opt-in is necessary. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
On 28 August 2019 15:39:26 BST, Marco Pivetta wrote: >I worked with clients with much more log overhead happening: the >solution >is working to fix these issues, and not ignoring more of them. Being right is not the same as being easy, or being the top priority for an organisation with limited resources. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
On 28 August 2019 15:24:33 BST, Mark Randall wrote: >By the very nature of using @ to suppress error messages, the examples >given are all fully aware that the behaviour they are using is not good >practice. I think that is a fault in the examples. I have never seen @ used to squash these messages, but have frequently worked with codebases where logging at the E_NOTICE level would have filled megabytes of log file in minutes. As I said earlier, the fact that something is bad practice doesn't stop it being difficult to locate and change. The requests for a deprecation period, or an opt-in mode, are about that change, not a disagreement about the principle. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] get_class_vars() and typed properties
On 18 August 2019 11:14:52 BST, Nicolas Grekas wrote:
>Le dim. 18 août 2019 à 11:59, Benjamin Morel
>a
>écrit :
>
>> Hi Internals, I just noticed the following behaviour:
>>
>> class A {
>> public int $a;
>> public ?int $b;
>> public ?int $c = null;
>> }
>>
>> $a = new A;
>>
>> var_export(get_object_vars($a));
>> var_export(get_class_vars('A'));
>>
>> Result:
>>
>> array (
>> 'c' => NULL,
>> )
>> array (
>> 'a' => NULL,
>> 'b' => NULL,
>> 'c' => NULL,
>> )
>See https://bugs.php.net/78319
>get_class_var() does the most useful thing, thus the correct one to me
>and
>the use cases I have.
This is a nice example of something I said when typed properties were being
added: "uninitialised" is a new special state, distinct from "non-existent" and
"null". As such, a non-nullable typed property without default value is
impossible to represent accurately without having a representation of that
state.
One rather ugly possiblity in this case would be to have the values returned be
"uninitialized", so that accessing the array keys was valid, but accessing the
values gave an Unitialized Value Error. That would be pretty horrible for
backwards compatibility, though, particularly for get_class_properties, where
there's no chance for the constructor to run and set up a real value.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Namespace-scoped declares, again
On 14/08/2019 11:17, Michał Brzuchalski wrote:
Following that would introduce unneeded additional directory hierarchy
level in a usual library
which uses PSR-4 which is the most used one, right?
/composer.json
/src/Foo.php
/src/Foo/ <- all package classes should go here?
That would be one place to put it, yes. But it would be entirely up to
how people wanted to define their autoloader, that's the beauty of it.
There's no reason something couldn't generate an autoloader that
essentially said this:
function autoload($name) {
if ( $name == self::PACKAGE_NAME ) {
require self::SRC_DIR . '/__packagedef.php';
} elseif ( str_begins_with($name, self::BASE_NAMESPACE) ) {
require self::SRC_DIR . str_replace('\\', '/', $name) . '.php';
}
}
Please don't pick holes in that implementation; my point is, if this was
how packages were implemented, people would decide how they wanted to
use it, and PSR-4 would probably be superseded by something which
accounted for packages existing.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Namespace-scoped declares, again
On 14/08/2019 11:07, Michał Brzuchalski wrote: Exactly so how would it know from string name either it should load class from src/Foo.php or src/__nsmeta.php if there is no information? It wouldn't. It would include src/Foo.php, and that would have the definition of something with the name "Foo" - either a class, an interface, a trait, or a package. If it wasn't what the engine was expecting, it would be an error, just as it is right now if you write "implements ClassName", or "new TraitName();" Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Namespace-scoped declares, again
On 14/08/2019 10:27, Michał Brzuchalski wrote:
But that's conflicting with you above idea for package definition like
that:
That's not what I'm suggesting; perhaps my example could have been
clearer. I envisage two new keywords:
- To put some code in a package, you would write "package Foo;" at the
top of a file, or "package Foo { }" around a block, in the same way you
can do now for namespaces and declare() statements.
- To define a package before it is used, you would write "packagedef Foo
{ }" around some block of pseudo-PHP that defined the options for that
package. That might involve using declare() directly, or might just be
an array that defines the options.
You suggest that it would trigger autoload to load "MyVendor\MyPackage"
but current autoload machinery is able to load only classes,
not even functions or consts! cause it gets the only class name now.
It would need to be changed anyway.
As I said in another reply, this is only the same change that needed to
be made to support "trait" alongside "class" and "interface", or would
be needed to support "enum" or "struct". The userland part of the
autoloader already doesn't know which of those it's looking for, so the
only constraint is that the names can't collide, so you couldn't name a
package the same thing as a class.
There are other problems with autoloading functions and constants, but
the relevant point is that you can define function foo() {} and class
foo {} in the same namespace; as long as you couldn't also have a
separate package foo{}, it could share the same autoloader as classes,
interfaces, and traits.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Deprecate PHP's short open tags, again
On 14/08/2019 09:39, Peter Kokot wrote: Code is like a garden. If there are unwanted weeds and nobody cleans them up, the flowers don't shine and grow as they should. Cleaning of the weeds is just as important as new features. A bit less but important. It's a pretty analogy, but I don't think it works. The things that make weeds a problem are that they take up space, they take up nutrients, and they spread. I don't think short open tags does any of those things. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Namespace-scoped declares, again
On 14/08/2019 07:45, Michał Brzuchalski wrote:
It doesn't have to be a new syntax if we agree to put package definiction
in sort of separate configuration file.
With the exception of INI files, all your examples are new syntax, as
far as the internal mechanisms in PHP are concerned. They have the
advantage of not inventing our own, but the disadvantage of needing our
parser to handle all the ways people might write them (particularly true
for YAML).
That way it would prevent to mix normal PHP code with package definition,
cause every possible PHP syntax
we would agree, opens the door to add something more to that file, for eg.:
# package.php
I don't see this as a problem. Right now, PHP doesn't care how many
files you put your code in. As far as I know, you could concatenate the
entirety of Laravel into one PHP file, and applications would not be
able to tell the difference. Similarly, you could put the whole thing in
a database and use eval() to execute it without touching any files.
In the same way, we can have a package definition not as a configuration
file, but as a piece of PHP code that needs to have been executed. In
practice, people wouldn't write what you have there for the same reason
they don't write this:
# foo.php
I think what attracts me to this idea is precisely that it doesn't
require much extra machinery. We could even use the trick that PHPStorm
uses for metadata stubs [1], and make the package definition look like
valid executable PHP, but never actually execute it:
package Foo {
const declare = [
'strict_types' => 1,
'strict_operators' => 1
];
}
That way, we can probably reuse the whole parser infrastructure, and it
looks entirely natural to a PHP programmer.
[1]:
https://blog.jetbrains.com/phpstorm/2019/02/new-phpstorm-meta-php-features/
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Namespace-scoped declares, again
On 13/08/2019 23:28, Mark Randall wrote: On 13/08/2019 21:26, Rowan Collins wrote: Ah, that makes sense. Does that necessarily mean we need a dummy class, though? The autoloading logic in the engine knows that it called the autoload callback expecting a package definition, so can count as success that the package is now defined. In other words, the file the autoloader included would look like this (again, sticking to the notion that "package" is separate from "namespace"): Personally with file-level opt ins I'm not 100% sold on the benefits of packages over namespace level information. I guess I'm not certain on what problem they're trying to solve that's different from just another object at namespace level. The problem they're trying to solve is that at the moment, there is no namespace-level information. Namespaces form an arbitrarily deep hierarchy, and don't need to be declared before they're used; it's hard to retrofit configuration into that. In my mind a package would be very similar to a namespace, but would have a mandatory declaration somewhere, giving a place to define its settings and properties; and there would be no "sub-packages", so no need to define inheritance and over-rides. As for the dummy class, the only real benefit is that existing autoloading procedures can be used to locate it and be included with minimal overhead. PHP can call the autoloader internally but it would require userland loaders to be upgraded with it, not exactly a huge stretch, especially with most things being composer-based, but a dummy class would make it work out the box, including optimization steps like dumping the class list. I see what you mean; but the change needed to autoloaders would be pretty minimal: if they just turn the name into a file path and run file_exists(), no change at all; if they tokenize files in advance to build a class map, they would need to add "packagedef" to the list of tokens to search for, alongside "class", "interface", and "trait". The same change would be needed if we introduced a "struct" or "enum" keyword, and I don't think anyone would expect to write dummy classes alongside those. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Deprecate PHP's short open tags, again
On 13 August 2019 19:19:42 BST, Olumide Samson wrote: >Not sure what the counter argument is really driving at. >So, because some people are using a function or an unworthy directive, >then >there can't be a major change in that aspect? That's not what anyone is saying. What people are saying is that we shouldn't just make changes because we feel like it; there should be a strong reason for the change. Most people probably even agree up to that point, but disagree with whether the reasons given for this particular case are strong enough. >Not sure where this project is headed, some will want a code to stay >because they want easy version upgrade(must everyone upgrade? ) and >those >who want to shake things up won't be allowed to do so. I find it really frustrating that this feature, that most people had probably forgotten even existed, has somehow been taken as an example of the pressing need for change. If you propose something that will actually take the language forward, but needs to break a few things along the way, then you might have a valid complaint about lack of vision. But there is no feature which will be unlocked by removing short tags; no big selling point we can talk about at conferences; it will either work, or it won't, and most people's code will not be affected one way or the other. Most people's wishlists for PHP, even some of the posts in this thread, include things like generics, union types, enums, CoW classes/structs, annotations. To my knowledge, none of those is currently being blocked by the need for backwards compatibility; most are being blocked because they're hard to design, and hard to implement. The best counterargument I can give against "cleaning up" is that it takes energy away from actual new features, even if it's just the mental energy of monitoring and responding to long threads like this one. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Namespace-scoped declares, again
On 13/08/2019 18:40, Liam Hammett wrote:
This already works (except for the "encoding" declare, which would make
little sense halfway down a file).
spl_autoload_register(function ($className) {
declare(strict_types=1) {
include $className . '.php';
}
});
This, however, doesn't, because each file has to declare its own
options, so we'd need some new syntax for "include with current parser
options". It would also lead to the possibility for the same file to be
included twice with different options, which would be confusing; or for
it to be in OpCache twice with different options, which would be complex
to implement.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Namespace-scoped declares, again
On 13/08/2019 18:45, Mark Randall wrote: I thought about this as my first consideration, however it effectively requires that the PHP code within the package class is fully parsed and executed in order for it to retrieve the data. Consider pre-loading where the code is compiled, but not run, it would not be possible to use namespace level defines to add compile-level optimizations or checks (at least without some AST hackery). Ah, that makes sense. Does that necessarily mean we need a dummy class, though? The autoloading logic in the engine knows that it called the autoload callback expecting a package definition, so can count as success that the package is now defined. In other words, the file the autoloader included would look like this (again, sticking to the notion that "package" is separate from "namespace"): # # File: /lib/company/project1.php # http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Namespace-scoped declares, again
On 13/08/2019 12:01, Mark Randall wrote: On 13/08/2019 10:02, Rowan Collins wrote: I really like this approach. It allows a package definition file to exist, without either the language or the header of each file having to define its location. # # File: /lib/company/project1/a/b/MyClass.php # This seems to be more complicated than Nicolas's version, and involve much more special magic, like the name __nsmeta, and the class that does nothing. I'm also not clear on how you're picturing the relationship between namespaces and packages. The way I understood the suggestion, you'd end up with something more like this, which feels much simpler and cleaner: # # File: /lib/company/project1/a/b/MyClass.php # 1, 'strict_operators' => 1, 'upgrade_errors_to_exceptions' => E_ALL ]; } } Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Namespace-scoped declares, again
On 12/08/2019 09:17, Nicolas Grekas wrote: Individual files could declare their package using this style: I really like this approach. It allows a package definition file to exist, without either the language or the header of each file having to define its location. Importantly, although it would trigger the autoloader if not yet defined, the package could be defined in advance, for instance as part of a preload directive. It could even be possible to define multiple packages in one file, or define them dynamically, using all the existing features of the language like require and eval. On a bikeshedding note, I've never liked the way declare syntax looks, so would prefer a new keyword, but the symmetry of replacing declare(strict_types=1); with declare(package=Something\Defining\StrictOptions); is admittedly quite appealing. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again
On Thu, 8 Aug 2019 at 16:18, Arvids Godjuks wrote: > BC is great, but you need to pull the cord at some point. And the whole > short tag back and forth, with deprecation warning and stuff, has been > around for last half a decade. It is time to accept that it needs to go > That's like saying from now on we should mandate PSR-2 indenting style in the compiler, to stop people arguing about code formatting. Just because people keep saying something, doesn't make it right. > If the old guard starts to push back as much as I have seen here, we are > going to lose momentum as a community and have people not willing to work > on PHP as much. > I feel like the opposite: if people volunteering their time find that all their energy is spent on pointless arguments about removing working features, and none of it is spent on actually innovating the language, they'll spend it somewhere else. > Long story short - indecision is not an option. Here's a decision for you then: short tags are fine how they are, and we can stop wasting energy talking about them and get on with doing something that actually benefits the language. That's not indecision, that's a concrete position we could take to prioritise our efforts on something more productive. The previous RFC has > passed. Everyone involved, I hope, understands that yes, there will be > stuff going wrong for some users who are careless and/or ignorant and live > under a rock. Can we really do anything about that? Yes. Yes, we can. We can do what's proposed in the v2 RFC, or we can reverse our decision. An RFC passing isn't a pact with the devil. > Let's look into the future, use a reasonable amount of caution and/or > deprecation notice periods, but please stop trying to block features > What is the feature being blocked if we leave short tags in PHP? If such a feature existed, I would understand your frustration - but if it did, the RFC could make the case for why adding that new feature was worth the pain caused by removing the old feature. Since there is no such feature, there is no such justification in the RFC, which is why it's so controversial. Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again
On 8 August 2019 13:16:56 BST, Brent wrote: >I asked similar questions on Twitter, where Zeev replied the >following: > >> With an estimated number of PHP developers >> at 10M, 1% is 100K. Whether I know this for >> sure is not at all the point - it's never how we >> take decisions. The question is whether it's >> reasonable or not. And my guess is that a lot >> more than 1% uses short tags. > >It feels like much of the counter arguments are based on guesses >without any real data to point to. You can take that both ways though: the argument that short tags should be removed is based on the same guesses. I understand Zeev's frustration in being asked to provide the proof when his position is that we shouldn't be spending any time on the issue at all. It should be up to those who think a change is necessary to demonstrate both the harm of the status quo (e.g. real-world cases of code exposure), and that it outweighs the cost of change (e.g. how many users will need to change working code). It would be different if we were choosing between two versions of some feature, but no-change should always have a starting advantage over change, which is why we require a super-majority in primary RFC votes. Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again
On Wed, 7 Aug 2019 at 20:45, Sergey Panteleev wrote: > Hi there! > > Perhaps I missed and someone already suggested, > but didn't consider a compromise option: > just change the default value short_open_tag=false, > and DON'T removes the option from php.ini? > > If someone uses short tags - ok, they will change > the default value to true and everything will be as before, > who won't change it - will enjoy the full syntax > Defaulting it to "off" would risk leaking people's code if they didn't set it, but I suggested earlier that it could default to a new "error" mode (which could also be explicitly set): https://externals.io/message/106384#106408 Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again
On 07/08/2019 09:11, Nikita Popov wrote: To clarify: What I had in mind is that use of in PHP code requires an explicit short_tags=Off right now, so the situation there shouldn't change, unless I'm missing something. Since it would behave differently, it wouldn't make sense to say that it defaulted to "On", but that actually leads to an interesting feature: add an "error" mode to that setting. So the options would be: - error: any use of "error; compile-time default - off: "by most packages - on: "We could either leave the recommended ini setting in the official distribution as "off" (more compatible) or set it to "error" (to make mistakes safer and easier to spot). Regards. -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again
On Tue, 6 Aug 2019 at 17:59, Chase Peeler wrote: > I'm not a voter, but, I have a question. If this fails, does that mean the > original RFC that passed is still in effect? > Yes, this is really ambiguous, and risks the situation being even more confusing than it was before. The "No" column on this RFC already includes people who voted "Yes" on the previous version; is this an indication that they have changed their mind about removing short tags, or that they prefer the original proposal? I think we urgently need to clarify this, and may need to reset the vote with one or more clearer questions. Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV] Improve visibility of RFC negative feedback
On Tue, 6 Aug 2019 at 14:46, Lynn wrote: > The current setup allows for a single author to write down counter > arguments. As the counter arguments seem to primarily be opinionated, I'm > interested to see who's opinion it is, as two people can have different > opinions on the same subject. If person 1 writes down "option A is bad > because of X", person 2 wants to write down that option A is also bad, but > not for the reason mentioned by person 2, and person 3 wants thinks the > arguments mentioned are actually pros and not cons, I don't see how that is > possible right now. > Dan's proposal covered that: > In the (hopefully) rare cases where the people providing negative > feedback can't agree on how that page should be formatted, they may > create a new negative feedback page and also put a link to it on the > actual RFC page, next to the other 'negative feedback' link. > That being said, I feel like this should be more of a personal summary per > person so everyone can look back what the opinions were and why someone > voted yes or no. > That sounds like something rather different from what Dan was proposing, and something that's been discussed before: require voters to give reasons for their votes. I won't go into the pros and cons of that right now, but will highlight why it's fundamentally different: A "negative feedback" / "counterargument" / "dissenting opinion" page is by design a *summary*, designed to *reduce* the amount of reading required to understand the additional viewpoint; a page for every user on the list would not achieve that design goal. This also comes back to the distinction between consensus and majority. If no two participants in a discussion can agree on even a summary of what the issues are, then we have a far bigger problem than how many wiki pages to create. Most voting reasons would amount to "I agree with point 4, but disagree with points 3 and 8", rather than needing to restate the whole case. Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV] Improve visibility of RFC negative feedback
On Tue, 6 Aug 2019 at 13:54, Lynn wrote: > Taking the current RFC ( > https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags) as > example, how do we as reader differentiate between people's counter > arguments? When I read those points, I feel like this is something agreed > upon by the group as a whole, rather than a person and I know that not > everyone might these points as (valid) counter arguments or have different > opinions about each. > > My proposal is to add a name to either a section or argument itself, or > perhaps each person could create a page with their counter arguments, > meaning the current page becomes an index. This makes it very clear to see > who provides which arguments. > Firstly, I would somewhat question why you need to know who holds an opinion. RFCs, and any dissenting opinions, are not manifestoes in elections, they are information presented so that you can form your own opinion. They should not be read as representative of "the group as a whole", but nor should the author be particularly important in most cases. That said, the current RFC template has an "author" field in the header, and Dan already proposed a convention of contributors "signing" dissenting opinions they agree with. The example you link to says "Author: Zeev Suraski", so I'm not sure what change you're proposing. Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV] Improve visibility of RFC negative feedback
On 5 August 2019 14:33:53 BST, Dan Ackroyd wrote: >When someone creates an RFC, near the top of that page they should >create a link to a separate page that will contain negative feedback. >People other that the RFC author are free to put whatever negative >feedback think is appropriate on that 'negative feedback' page. Hi Dan, I think this is a really sensible idea. The key difference between an RFC and a discussion thread is that it presents a summary or synthesis, which can be much more easily digested than a full discussion. It is also, crucially, editable, so can be reworded or corrected to clarify points; in an email thread, a reader often has to read the first attempt at conveying something, then follow a series of errata down the sub-thread. As Zeev mentioned, it might be enough to have a standard format for this, rather than always requiring it. I also think the term "negative feedback" might be a bit ... negative. Elsewhere in your message, you used "dissenting", which I think captures the essence better. The difference from the main page is not inherently about positive vs negative, but about allowing different voices. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Namespace-scoped declares, again
On Tue, 30 Jul 2019 at 17:27, Mark Randall wrote: > At the point we're talking about composer integrating callbacks, > preloading lists etc, isn't it about time that an spl_autoload_list was > added that accepted the standard composer classmap [class_id => path] > and forewent most autoload callbacks entirely? > To be honest, at this point autoloading is barely necessary: just ensure OpCache is configured correctly and preload all the files. When I tested an exhaustive class map with OpCache disabled, it was actually slightly slower than a "non-optimized" autoloader, presumably because the array definition itself takes so long to compile. Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV] Re: [RFC] Namespace-scoped declares, again
On Tue, 30 Jul 2019 at 15:08, Nikita Popov wrote: > 5. Introduce a first-class module/package concept and support per-package > declares. This is arguably the closest fit for what is needed, but also the > most complex solution. This is a fairly big problem space and I personally > do not want to pursue this outside a certain narrow scope. > > In particular I have serious doubts about retrofitting (at this point in > time) an invasive module system that involves explicit export and import > management, along the lines of what Michal is describing. (Though I will be > happily surprised if someone comes forward with a proposal to do this in a > non-invasive way.) > > What I think might be worth pursuing though, is a much weaker package > notion that essentially grants some language-integration to the existing > notion of composer packages. Instead of having a declare_directory() we'd > have declare_package(), which is bound to a certain path and can be used to > specify declares, but also used for other purposes, such as package-private > visibility. > > If I may make another Rust analogy, this would be more like Rust crates > than Rust modules. The analogy being that this is a more coarse grained > level, and is fairly tightly integrated with the package manager (but of > course still usable without it). > Yes, I was thinking of something more like Composer packages, rather than like JS modules: code would mostly work as presently, but with some notion of being "owned" by a particular package. This doesn't mean all the functions of Composer would be integrated, but could provide richer primitives, such as registering an autoload callback or preload list to a particular package, rather than having to perform string matches. Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV] [RFC] Explicit call-site send-by-ref syntax
On Tue, 30 Jul 2019 at 11:28, Nikita Popov wrote: > With that in mind, I don't see an issue with reusing the previous > call-time pass-by-ref syntax here. The & at the call-site still means that > the value is going to be passed by refrence (or error), so it's not like > someone who was around during the call-time pass-by-ref times would > misunderstand what the code does based on their prior knowledge. > > The only concern I see here is the emotional issue: Bringing & back as a > call-site annotation is an admission that the original migration of by-ref > passing has been badly botched: Yes, you removed those & at the call-site > for nothing. Yes, you shouldn't have been forced to do that! > > Mistakes happen and hindsight is 20/20. But we should own up to those > mistakes. > I think that's a reasonable summary. Could you add a short section to the RFC just acknowledging that history, and clarifying that this functionality is effectively a subset of the previously removed feature, but without its problems? You're right that it's more of an emotional reaction than a rational one, and shouldn't necessarily be a show-stopper IF we agree the proposed behaviour is a big enough gain. Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV] [RFC] Explicit call-site send-by-ref syntax
On Tue, 30 Jul 2019 at 10:00, Nicolas Grekas wrote: > Call-time pass-by-reference is deprecated since PHP 4.3.0 and triggers a > deprecation warning since then: > https://3v4l.org/MFXsJ > > That's since Dec 2002. > It looks like the history is more complicated than either of us are remembering. I based my assertion on the migration notes for PHP 5.3 [1] which simply say: > Call-time pass-by-reference is now deprecated. However, that looks to have been the result of an RFC [2] which gave more background. According to that page, it's actually a PHP 3 feature, retained through PHP 4 and PHP 5, with an option to disable it (at the time of that RFC, there was still going to be a PHP 6). But since no warning was issued if you left the option in its default state, most users had no idea that it was considered deprecated, and carried on using it. So the first time many people heard that they needed to stop marking their call sites was PHP 5.3, released in 2009 and EOL in August 2014. [1] https://www.php.net/manual/en/migration53.deprecated.php [2] https://wiki.php.net/rfc/calltimebyref Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV] Re: [RFC] Namespace-scoped declares, again
On Tue, 30 Jul 2019 at 09:12, Michał Brzuchalski wrote: > 1) Packages should be non-hierarchical. Perhaps most simply a package name >> could have exactly two parts, like in composer, so it's clear that there is >> no implied relationship between two packages. >> > > IMO this would create a lot of problems cause name in Composer Package > doesn't reflect used namespace declared in autoload > I'm not saying the package name has to match the composer name, just that the format might be similar; and I explicitly left the question open of how package names would relate to namespaces. It might be sensible to align the package/module name with one or other of the existing two naming schemes, but it's certainly not essential; names in Composer are essentially arbitrary anyway, not visible at all at run-time. On Tue, 30 Jul 2019 at 09:20, Lynn wrote: > Would it be an idea to first establish the concept of a package within > PHP, rather than deducting it based off a namespace? If packages would be a > thing in PHP, other than just a namespace, package private could also be > implemented as visibility modifier for inheritance and class visibility. > I think there's some confusion here, because establishing the concept of a package as separate from a namespace is exactly what I proposed. Here's a previous message (technically in the same thread, but from 18 months ago) where I also mentioned class visibility: https://externals.io/message/101323#101390 Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV] [RFC] Explicit call-site send-by-ref syntax
On Tue, 30 Jul 2019 at 07:14, Nicolas Grekas wrote: > I think enough time has passed since php4's call-by-ref for the syntax to > be > reused now. I think it's unfair to call the RFC a reminiscent of > call-by-ref BTW. > Firstly, please let's stop calling this a "PHP 4" feature. It was fully supported right up to 5.2, deprecated in 5.3, and only removed in 5.4. Secondly, I completely disagree that it's unfair to compare the two. The syntax being proposed in this RFC (& at both call-site and definition-site) was supported by versions prior to PHP 5.4. Those versions left it optional at either side, which was certainly a mistake; but it was perfectly possible (and probably common) for coding standards to require it in both locations. It might be a good idea to include a more thorough discussion of this history in the RFC. > About requiring such call-annotations using a "declare" directive it feels > like a heated topic. But we don't need it, so let's split it appart. I > could very well see userland tools enforce it at the CS-checking level. > That would provide 99.999% of the target benefit > Unfortunately, it doesn't bring any of the benefits to static analysis that Nikita is proposing. Indeed, it relies on existing static analysers correctly finding the function definition to complain whether the optional & is in place. Including it as optional would certainly bring some benefit to readers, but I think it's a lot less than "99.999%" of what making it mandatory would bring. Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV] [RFC] Explicit call-site send-by-ref syntax
On Mon, 29 Jul 2019 at 15:41, Nikita Popov wrote:
> This proposal (at least combined with a declare that enforces use of
> call-site annotations) addresses that concern. out/inout parameters do not
> address this concern, because they are an mechanism that would be used *in
> addition* to normal by-ref passing, and as such not address any problems it
> has.
>
> The only way I see in which out/inout would actually address the concern
> of this proposal is if out/inout were used instead of & at the call-site,
> but the parameter were still a normal reference. I don't think that's a
> good idea because it breaks symmetry between arguments and parameters, and
> also squanders any future potential to use out/inout as a way to reduce
> reference-use in this context.
>
> Does that make sense, Rowan? To put is more compactly, what I want is an
> eventual state where given $fn($a) I have a guarantee that $a is not going
> to be magically modified, without having to perform any global reasoning
> about what $fn may refer to. If an alternative proposal does not result in
> this eventual state, then it is not an alternative to this proposal (but
> possibly still a valuable addition in itself).
>
It does, yes. I guess what I had in mind was that *in the long-term*,
out/inout parameters would replace & parameters, so rather than
declare(require_reference_at_call_site=1) you would have
declare(disable_reference_parameters=1).
Whether or not it's a direct alternative to this proposal, I also worry
that out/inout parameters are somewhat mutually exclusive with it: the more
effort is spent on making reference parameters "better", the less appetite
there will be for replacing them altogether. I agree the behaviour of type
annotations would need deciding, but arguably that should have been true
for by-reference parameters; it's somewhat bizarre that you can write
"function foo(SomeClass &$x) { $x=42; }" The solution would probably be to
reuse the "typed references" from the typed property implementation.
> Bob has brought up another interesting issue: This proposal currently does
> not address the case of foo(...$a), where references into $a may be added
> if foo() has by-reference parameters. The suggestion was to use foo(&...$a)
> -- however in this case only to *allow* the use of references, not require
> it (some args may be by-val while others may be by-ref).
>
There's probably a bit of a rabbit-hole if the mission is "make references
explicit". An array containing a reference can be passed by value, for
instance, so $fn($a) might not technically modify $a, but still modify
elements inside it. So it seems like we come back to "this is kind of
useful information but may not actually offer a hard guarantee".
Regards,
--
Rowan Collins
[IMSoP]
Re: [PHP-DEV] Re: [RFC] Namespace-scoped declares, again
On 28 July 2019 18:56:24 BST, Dan Ackroyd wrote: >I look at the success of how strict types was brought in, in a way >that allowed for zero breaking changes for existing code, and think it >was a massively successful way of improving the language without >causing problems. I think it's a) very early and b) very subjective to call that decision "massively successful". I have had conversations online and in person asking both why there are two modes, and why the mode can't be selected globally. It was a classic compromise that neither side of the debate hated, but neither really loved either, and the subtleties of how each mode works are likely to be sources of confusion for years to come. I am far from convinced that it is a model we should enthusiastically seek to repeat. Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV] Re: [RFC] Namespace-scoped declares, again
On 25 July 2019 14:34:07 BST, Nikita Popov wrote: >Based on the received feedback, I plan to change this proposal from >being >"namespace-scoped" to being "directory-scoped" instead. This should >both >resolve some of the concerns and make the proposal more flexible: Not >all >code sharing the same namespace is part of the same package (multiple >packages may have classes in the same namespace) I think the word "package" here is significant, because all the other variants of this proposal come down to "how can we best emulate package/module support": - the original namespace form assumes that some level of the namespace hierarchy represents a package - the proposal to use a directory assumes that some structure on disk represents a package - Mark's alternative using an explicit include allows every file to say it's part of some package I think it would be better to skip these workarounds, and define a package directly. The differences I see between package and namespace are: 1) Packages should be non-hierarchical. Perhaps most simply a package name could have exactly two parts, like in composer, so it's clear that there is no implied relationship between two packages. 2) A package should be explicitly declared before first use, probably in a separate file. This definition would have scoped declares, and could also have autoload and preload definitions. Or perhaps a package would always be eagerly loaded, allowing us to do more cross-file analysis at compile-time. Obviously, there's a lot to figure out here. Do we define where the package definition lives on disk, or require the user to configure it in some way? Does a package name form the prefix for namespaces within that package, or can a package contain definitions for any namespace? However, I think we should make these design decisions, rather than letting an easy implementation lead us somewhere we'll regret later. I do also share the concern that a proliferation of package options would make the language harder to understand. Part of the motivation for removing short open tags seems to be to make the language more consistent. The ability for a package to configure the compiler as its author intended is certainly better than having to test every combination, but we need to think very carefully about what options we add. Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV] Re: [RFC] Explicit call-site send-by-ref syntax
On Thu, 25 Jul 2019 at 16:18, Nikita Popov wrote: >> That would stop people having to write `$matches = []; preg_match($foo, $bar, $matches);` > Eww, please don't write code like that... Huh? How would you write it then? The behavior of type annotations should also change, "out T $x" should > check that the value assigned to $x on function exist (or possibly on every > write to the variable?) is T. "inout T $x" should check that $x is T on > entry, and also on exit (or on every assignment). > Ah, you're right, I hadn't thought about the implications for type checks. Still, I'd rather wait for an actual new feature like this than dig into my repo and revert the PHP 5.4 update commit so that all the call-site ampersands are back, but still with all the drawbacks of references. Contrary to the RFC, I have never thought of this as "PHP 4 behaviour", because I used it right up until 5.3, exactly how this RFC is now suggesting is the future. (I guess I should have paid more attention to deprecation notices at the time!) Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV] Re: [RFC] Explicit call-site send-by-ref syntax
On Thu, 25 Jul 2019 at 14:48, Nikita Popov wrote: > I think nowadays it is well known that by-reference passing is to be > avoided and I don't see it particularly commonly in user code. By-reference > passing is mainly used when it is needed to interact with existing > by-reference functions such as preg_match(). We can hardly switch these > functions to use out/inout if we require the corresponding keyword on the > call-site. > I guess the call-site syntax would still need to be opt-in for compatibility reasons, but we could definitely mark the parameters as "out" in internal functions, even if that was mainly a documentation / reflection change. That would stop people having to write `$matches = []; preg_match($foo, $bar, $matches);` to ensure that the output parameter is initialised. I have been annoyed by that more often than I've encountered a function where I wasn't sure if the parameter was by-reference or not. This proposal (in conjunction with the option to make it required) would > solve the main issues I have with the by-reference passing implementation > If this remains optional, I wouldn't have much appetite for using it, because the benefit feels very slight. The fact that it wouldn't always be mandatory makes the benefit even slighter, since you still couldn't look at foo($bar) and know whether it was by-reference without also knowing what declare options were in scope. > the out/inout approach is a refinement over that, but I'm not convinced > that it a worthwhile refinement relative to the language and engine > complexity it will introduce. > Would it really be that complex? The only real difference between "out" and "&" would be automatically setting the variable to null when it was passed to the function. Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV] Re: [RFC] Explicit call-site send-by-ref syntax
On Thu, 25 Jul 2019 at 13:32, Nikita Popov wrote: > I think it can either go forward as-is, in that it constitutes the first > step towards bringing sanity to by-reference passing in the long term. > Hi Nikita, As I mentioned before, I think this RFC is 10 years too late: if this goes ahead, we'll be telling a lot of people "You know all those reference annotations you removed when you upgraded to PHP 5.4? You have to put them all back again now!" To be clear, forcing a parameter to be by-reference against the signature of the called function was a bad feature, and this proposal would have been better. But without a time machine, I think this will cause more confusion than it brings value. Adding "out" and "inout" keywords, as mentioned in "future scope", is a much more powerful change, won't require any opt-in modes or breaks to existing code, and would be looking forward rather than backward. It's hard to see how tweaking the meaning of "&" will lead us closer to that, making it feel more like "alternative" than "future". (For those without threaded mail clients, the RFC in question is https://wiki.php.net/rfc/explicit_send_by_ref Incidentally, the "Proposed for" on the RFC needs updating!) Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV] Re: hebrevc() and other 'contentious' 7.4 proposed deprecations
On Tue, 23 Jul 2019 at 12:12, Johannes Schlüter wrote: > A good reading on consensus in technical discussions is this: > https://tools.ietf.org/html/rfc7282 I just skimmed that document, and I think there's a lot we could learn from it, if we had the confidence to truly reform. You could pretty much replace "IETF" with "PHP" in this paragraph, and you'd have a summary of why we *shouldn't* rely on votes as much as we do: > We don't vote in the IETF. In some ways, we can't vote: Since the > IETF is not a membership organization, it's nearly impossible to > figure out who would get a vote for any given question. We can't > know who the "members" of any given working group would be at any one > time, and we certainly can't know who all of the "members" of the > IETF would be: That's why we refer to "participants" in the IETF; the > IETF doesn't really have "members". > On hebrev()/hebrevc(): I believe most contributors have no idea what it > does and I for one have no need. It doesn't hurt me, though. As long as > it works for the users I'd keep it since cost is low. If I'd support > adding such a function in future is a different question. > I agree with everyone who has said removing a feature (and every "deprecation" is actually a proposal to remove something) should have a much higher bar than not adding it. I think there is also an extra requirement that removal (and therefore deprecation) should have, which many of these proposals *also* don't pass: what should people be using instead? To me, every deprecation note should be able to clearly say one of two things: - If you are using this feature, You Are Wrong. Don't do it, emulate it only as a short-term measure, work to remove it. - If you are using this feature, you should use this specific feature instead, because it is better in these ways. Take convert_cyr_string, for example. The RFC says "one of mb_convert_encoding(), iconv() or UConverter may be used for this purpose". There's a sleight of hand here - it sounds like we've offered the user an upgrade path, but we haven't actually said *how* to get the equivalent functionality. Why are there three options, all in different optional extensions? Will one of them be removed in a few years' time, leaving users to fix their code all over again? What options does each of these need to emulate the old function? Is it even possible, or will there be subtle differences that need testing? If the aim is to have a Right Way to do everything, we should be saying what that Right Way is. I picked this example in particular, because I'd actually love there to be better guidance on how to convert encodings, and I'd like to remove utf8_encode and utf8_decode, which I think cause far more damage by being so badly named. I haven't proposed it, because for the people who are using those functions correctly, there would need to be a clear replacement, and right now there isn't. Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV] [RFC] [DISCUSSION] Deprecate PHP's short open tags V2
On Wed, 24 Jul 2019 at 22:40, Peter Cowburn wrote: > Hypothetically, it can be re-evaluated sooner, particularly if "everyone" > in the PHP ecosystem appears to respond very well once the deprecation and > error stages happen. In fact, I wouldn't want "but we voted for 9.0" to be > a point being made if/when that discussion comes along. My point is that > the removal release/date, in my opinion, is a detail that we don't need to > be concerned with right now and it's just adding noise. You disagree, and > that's totally okay. > Regardless of when we have the conversation, I will remain opposed to removing it any time before 9.0. There's very little justification for removing it in the first place, so I can't imagine what justification there'd be to remove it 2 or 3 years earlier. The only advantage I can see of delaying the debate is to leave open the possibility of keeping the error into 10.0. If that becomes necessary, it will be a sign that something has gone wrong, because it will imply that takeup of 8.x was so low that people are still running code where this syntax is used. Sadly, given the current zeal for removing working features, I fear that may happen. Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV] [RFC] [DISCUSSION] Deprecate PHP's short open tags V2
On 23/07/2019 21:52, Stanislav Malyshev wrote: This RFC does nothing to eliminate code written for short-tags - it is impossible to eliminate with any RFC, in fact, it is impossible to eliminate at all. It does more to eliminate it than the previous RFC, by having at least one version where it generates an error, rather than being silently ignored. So the only question is what is happening when server is encountering such code. Yes, which is exactly what this RFC is changing, because although the previous RFC was accepted, concerns were raised that the details hadn't been fully considered. immediately visible in PHP 8.0. This RFC removes that danger by amending the 8.0 behaviour to *explicitly detecting the tags* and throwing a ParseError. But only for 8.0. So if you have a bad luck of skipping .0 and going directly for .1 you're still in the same trouble. Yes, as I said elsewhere, I think 9.0 is a much better time for the full removal, and I hope the RFC will be amended appropriately. However, to reiterate, either is still later than the previous RFC. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [DISCUSSION] Deprecate PHP's short open tags V2
On 23/07/2019 21:22, Stanislav Malyshev wrote: Worse than that, code using short open tags deployed on a server using short_open_tag=0 will leak application code, because short open tags are silently ignored. That's precisely what this RFC is intended to prevent. By deprecating *and simply removing* the functionality, as implied by the previous RFC and initially implemented [https://github.com/php/php-src/pull/3975/], we would make such code immediately visible in PHP 8.0. This RFC removes that danger by amending the 8.0 behaviour to *explicitly detecting the tags* and throwing a ParseError. I am not sure how it is supposed to be an argument for making such behavior the default. This RFC does not make anything the default that is not already; instead, it keeps the INI option as it was before, but changes its behaviour: * In 7.4, the first use of "deprecation notice, but no other behaviour changes (as appropriate for a minor version) * In 8.0, any use of "Arguably, this could be considered a new implementation of the previous RFC, but it seems prudent to put it through the RFC process a second time to to avoid claims that it has bypassed the process in some way. Presumably if it doesn't achieve consensus, the previous plan would remain in effect. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [DISCUSSION] Deprecate PHP's short open tags V2
On 23 July 2019 18:54:48 BST, "G. P. B." wrote: >The only point of contention of this RFC that I potentially see is the >removal in PHP 8.1 after short open tags being a Parse Error in PHP 8.0 >instead of it being removed in PHP 9 after it having had a whole major >version release cycle. Given that you've already predicted that this will be controversial, could you provide some rationale for it? Unless there's a major burden in maintaining the parser error behaviour for a few years, waiting for the next major version would seem both safer and more in line with official versioning policy. As with deprecation itself, any violation of the "no breaking changes" rule, however slight, should have an explicit justification. If I had a vote, any RFC omitting such a justification would receive an automatic "no" from me. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Strict operators directive
On Wed, 26 Jun 2019 at 12:46, Benjamin Morel wrote: > This makes sense for "<", "<=", ">", ">=", but what about "==" and "!="? > > Currently, "11" == "11.0"; what would this yield under the new proposal? > > - leave it as is: return true in this case => contradicts the whole purpose > of the new proposal > - throw a TypeError when performing the above comparison => not acceptable > either I guess; every language allows == and != on strings, forcing to use > strict comparison operators is a bit weird here. > - change the semantics to return false when both operands are strings, and > don't match => not acceptable to you as you cannot know what a line of code > does without checking the header > Given that we already have === and !==, could the strict mode simply throw an error for *any* use of the non-strict == and != versions? declare(strict_operators=1); var_dump( "11" == "11.0" ); # TypeError: "Cannot use non-strict equality operator in strict operator mode." var_dump( "11" === "11.0"); # bool(false) I'm not sure whether I like the idea or not, but I thought I'd throw it out there as a possibility. Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV] [RFC] Strict operators directive
On Wed, 26 Jun 2019 at 10:36, Benjamin Morel wrote: > Oh, I see. You mean that only replacing some of the current results with > TypeErrors would be acceptable; returning a different value would not. > This makes a lot of sense, but once again prevents the language from slowly > moving towards something different (and better), leaving it stuck in its > legacy forever. > If we're talking about combining operator overloading and type juggling in the way that JS does it, I would definitely debate whether that's "better". It leads to the weird circular situation where to know what an operator means, you have to look at the types; but to know how the types will be interpreted, you need to know what the operator means. Perl is a notable contrast: the types of operands are deduced based on the operator, but there are different operators to force them to different types. So `23 < 4` and `"23" < "4"` are both numeric comparisons, so return false; but `23 lt 4` and `"23" lt "4"` do string comparisons, and return true. That way the user's intent is clear, but you don't have to manually cast values or remember how different combinations will be interpreted. > I'm starting to believe that a joint effort to fork PHP if the only way out > If what you want is a fork of PHP with stronger typing, then take a look at Hack https://hacklang.org/ Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV] [RFC] Desire to move RFC add_str_begin_and_end_functions to a vote
On 23/06/2019 16:29, Ben Ramsey wrote: According to Google, "İyi akşamlar” is the Turkish phrase for “Good evening” (Turkish speakers, please correct me, if this wrong). However, using the existing mb_* functions, I can’t get mb_stripos() to return 0 when trying to see if the string “İYI AKŞAMLAR” begins with “i̇yi.” Probably mb_string not using the right case-folding routines; as mentioned in another thread, ext/mbstring wasn't written for Unicode, but for older multibyte encodings, particularly those used for Japanese text. grapheme_stripos (from ext/intl) apparently gets it right as of PHP 7.3: https://3v4l.org/0431j A much simpler example, though, is using just the second word of that string: the accented "s" confuses plain stripos but not mb_stripos. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Desire to move RFC add_str_begin_and_end_functions to a vote
On 22 June 2019 20:56:24 BST, Ben Ramsey wrote: >Perhaps it would only be an issue with the case-insensitive versions, >as Nikita points out? If so, can someone provide some example strings >where an mb_starts_with_ci() would return true, while >str_starts_with_ci() would return false? That's easy: any character that has a lower- and uppercase form, and is not represented as one byte in the target encoding. For that matter, any such character in the non-ASCII section of a single-byte encoding, since a non-mbstring case insensitive flag would presumably leave everything other than ASCII letters untouched. So, any non-Latin script, like Greek or Cyrillic; any accented characters, unless you're lucky and they're represented by ASCII-letter plus combining modifier; the Turkish "i", which if I remember rightly has three forms not two; and so on. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Discussion] Scalar Object Strings and MultibyteEncodings
On 20/06/2019 23:30, Mark Randall wrote: There does at least seem to be the starting point in that mb_string is already widely used, and my suggestion that it "work as expected" is more that it would work as the equivalent mb_string / iconv function would. I think this is a rather short-sighted way of looking at it. If people want the API provided by the mbstring extension, they can just use those functions; the advantage of designing a new set of functions is surely that we don't need to stick to past decisions. If we start to build a new standard library, as Zeev suggested in the deprecation thread, it is a once-in-a-lifetime chance to build something better, not just copy what's gone before. mb_strlen returns the number of codepoints for example, I'm not immediately seeing anything about mb_string supporting Graphemes as the only reference I could find to their manipulation was The intl extension. The mbstring extension was not built for Unicode, but for older Japanese multi-byte encodings, where the definition of "character" is much more straight-forward. Its Unicode support seems to mostly see code points as mappings for characters in some other encoding. (The oldest manual page for it on archive.org [1] is from 2001, and includes the quaint remark "As Unicode is getting popular, UTF-8 is used also.") The iconv library is even more explicitly aimed at converting between character sets, rather than understanding them (the extra functions such as iconv_strlen are unique to PHP). Unicode today is much more than a mapping of legacy encodings to a universal character set, and I can think of no useful purpose in declaring the "string length" of the British flag emoji to be 2, just because it is encoded as the sequence U+1F1EC U+1F1E7. [1] http://web.archive.org/web/20010605075550/http://www.php.net/manual/en/ref.mbstring.php Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Deprecations for 7.4
On Fri, 21 Jun 2019 at 16:20, Kalle Sommer Nielsen wrote: > Greetings Internals > > Nikita and I would like to open the discussion for the RFC: > "Deprecations for 7.4", this RFC targets a larger set of various > features targeting for deprecation in 7.4 with the intention of > removal in PHP 8.0. > > https://wiki.php.net/rfc/deprecations_php_7_4 > The mention of "convert_cyr_string" here makes me want to revisit the oft-abused "utf8encode" and "utf8decode" functions. The downside in all cases is that PHP has no single correct function for encoding conversions, with mbstring, intl, and iconv all offering slightly different implementations, and all distributed as optional extensions. Is there some way we can bless a single conversion function, in core, and recommend that in deprecation notices? Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV] [Discussion] Scalar Object Strings and Multibyte Encodings
On 20/06/2019 16:36, Mark Randall wrote:
"Hello".substr(1) // would work as expected regardless of encoding
As I always point out when "multi-byte support" or "Unicode support" is
discussed, it's often ambiguous just what should be "expected".
A lot of systems go from "each character is one byte" to "each character
is one code point", but that leads to what I call "the noël problem": if
you reverse the string "noël", the expected behaviour is probably for
the diaeresis to stay on the "e". However, if it is encoded as a
combining diacritic, a code point based implementation will place it
onto the "l" instead. Similarly, taking the first three "characters"
should give "noë" not "noe". Enforcing normalisation helps in this case,
because there is a composed form of e+diaeresis, but that's not true for
all combinations ("graphemes") you can encode, or for all operations.
Another example is "length"; what practical purpose does "number of code
points" serve, when some of those code points may be combiners or
non-printing marks? Often, number of bytes (in some encoding, such as
UTF-8) is actually the relevant measure; other times, "width on screen"
is what is actually required, and very hard to compute.
My point is that any attempt to make the language "do the right thing by
default" needs serious thought on what "the right thing" is.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV][RFC] Normalize array's "auto-increment" value on copy on write
On Thu, 20 Jun 2019 at 13:11, Wes wrote:
> I left that out of scope for the RFC, for reasons I don't have the
> knowledge to describe properly. In the following example, `unset()` should
> reset the auto increment to `1` only after the third `unset()` call
>
> ```
> $array = [0, 1, 2, 3]; // auto increment is 4 because there are "holes" in
> the index
> unset($array[1]); // auto increment is still 4
> unset($array[2]); // auto increment is still 4
> unset($array[3]); // auto increment is 1, because the index sequence is
> contiguous, without holes
> ```
>
I wonder if it would be possible (and sufficient) to detect if the element
being removed was the highest key, and only then look for the new "next"
value.
The new value can be found either by decrementing the known value until you
hit an existing entry (optimal for large arrays with few gaps in the
sequence of keys) or by checking all the keys and finding the max (optimal
for small but sparse arrays like [12, 145, 65546]).
# pseudocode:
if ( key_being_unset == array.next_key - 1 ) {
if ( short_or_likely_to_be_sparse(array) ) {
new_highest_key = max(array.keys);
} else {
# Find highest unused number, starting from the one just deleted
do {
new_highest_key = key_being_unset - 1;
} while ( not key_exists(array, new_highest_key) );
array.next_key = new_highest_key + 1;
}
}
I've no idea if this is plausible or not.
Regards,
--
Rowan Collins
[IMSoP]
Re: [PHP-DEV] Generating arginfo from stub files
Hi Nikita, On Tue, 18 Jun 2019 at 16:10, Nikita Popov wrote: > I've created a proof of concept implementation for this at > https://github.com/php/php-src/pull/4284. Function signatures are > specified > in a xyz.stub.php file from which xyz_arginfo.h is generated. This file can > then be included in the implementation. Nothing about the arginfo > implementation itself changes. > I notice on the PR there was discussion of stubs elsewhere (e.g. https://github.com/JetBrains/phpstorm-stubs) still being necessary because they contain additional documentation. However, has the opposite been considered: process an existing set of stubs to remove unsupported or irrelevant annotations, and import into php-src with this tool? That way, the manual effort for existing functions would be virtually zero. Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV][RFC] Alternative "use" syntax for Closures
On Sat, 15 Jun 2019 at 23:22, Kalle Sommer Nielsen wrote:
> The proposed syntax was also that of the proposed syntax when closures
> arrived in 5.3 (and back then it was using the then keyword
> 'lexical'), anyway. I believe the current syntax was chosen due to
> scopes, as values are bound specifically when the closure is created
> and not when the closure is executed.
>
Hi Kalle,
Thanks for the background info, I've often wondered why the syntax isn't
more similar to "global" and "static" declarations. It hadn't occurred to
me before that the function signature can be processed without inspecting
the function body.
While I think the proposed syntax has its upsides, I agree with others that
adding it as an alternative at this stage doesn't add very much. People who
don't like explicit imports still won't like it, and people who are used to
the existing syntax will write style guides prohibiting the new.
When I suggested on SO chat that a long list of imports was a similarly bad
sign as a long list of parameters, I was scoffed at, so I would be
interested to see examples where large numbers of imports are justified.
Assuming there are such use cases, it seems like automatic capture will be
a better solution. I'm not personally keen on extending the arrow syntax
with a full body - "fn()=>{}" is barely shorter than "function(){}", and I
think "arrow functions are for short expressions" is a useful distinction
and constraint.
If we really need automatic capture, I'd prefer for it to be opted into in
the normal syntax, e.g. "function() use(*) { ... }". We could even have
"use(&*)" for "automatic capture by reference", if we wanted to go that far.
Regards,
--
Rowan Collins
[IMSoP]
Re: [PHP-DEV] The real world ...
On Thu, 13 Jun 2019 at 14:46, Lester Caine wrote: > Had I HIDDEN the warning the client would just have > ploughed on but now I can divert to fix the faulty bits of data and sort > the problem! It will be some silly thing missed, but in 20+ years of > code that are still a lot of those and simply hiding something and > waiting until later to clear the problems created is never going to be > right :( > Don't underestimate the ability of users to plough on in the face of the most obvious errors (and then on another day stop dead given the tiniest unexpected message). In this case, you already did "wait until later" - you waited until the client saw it, and had the time and inclination to mention it to you. There are far better solutions out there, as others have mentioned, that make sure *you* see the message in good time. Then you can call up the client and say "don't use this screen I think it's corrupting the data", rather than them calling you up after they've entered 1000 corrupted records. A generic message on PHP's default 500 error in place of the notorious white screen would probably be useful, but it should be limited to something like: > A system error has occurred. > Please contact the site administrator. > If you are the site administrator, please check your error logs for details of the error. Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV] Handling of null arguments to internal functions
On Thu, 6 Jun 2019 at 12:49, Arvids Godjuks wrote: > consistency, in general, would be a nice change of pace so you don't have > to keep in mind that there are slight differences in behaviour depending on > what you call - a built-in function or a userland one. > This is my view as well. Another thing that inconsistency causes problems with is polyfills - if you want to wrap, emulate, or otherwise reimplement an internal function, it can be fiddly to emulate the subtleties of ZPP. (This gets worse with objects, which can do all sorts of wacky things internally that have no user-space equivalent, but that's a topic for another day.) Would it be possible to use a combination of automation (analysis of the C code, or fuzz testing of the functions) and collaboration (a great big list people can work through a section of and report back) to categorise the functions in core? Something like: a) not affected, because handling is consistent with userland anyway b) should explicitly accept nulls c) should explicitly reject nulls We do however have to make a tricky judgement on functions in category c, of how much code is going to break if we make them stricter. Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV] [RFC] Escape PDO "?" parameter placeholder
On Fri, 31 May 2019 at 12:27, Matteo Beccati wrote: > Hi everyone, > > following some recent unrest in the comments of the related PR, I've > decided to invest a bit of time on it and finally move it to draft status: > > https://wiki.php.net/rfc/pdo_escape_placeholders > Hi Matteo, This sounds like a very useful change. As you say in the RFC, these operators are going to be more and more common for Postgres users now that they've been defined for JSON types, and users of most other DBMSes will be completely unaffected. I wonder if there's any way we can gauge the BC impact, specifically this case: > The only exception to that is that Postgres (and possibly other RDMSs) allows the creation of custom operators: anyone having a custom “??” operator in use would need to escape it as “”. - Are there any standard or public Postgres extensions that define a "??" operator? e.g. anything published on https://pgxn.org/ - Are there any other databases supported by PDO that allow custom operators, or which might have a "??" operator or syntax token? If there is a risk of this affecting a reasonable number of people, we could add a deprecation notice on encountering "??" in any SQL string in 7.4, and postpone adding the escaping mechanism until 8.0. One other thing worth clarifying is the precise circumstances where ?? will be treated as an escape. Is it only when it's a separate "word" (start/end of string or surrounded by whitespace)? For instance, would "A ??= B" be "unescaped" to "A ?= B" or passed through as is? Note that this changes the scope of the BC break, as well as the usability of the chosen syntax, as both "?=" and "??=" could be defined as operators. Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV] Re: [RFC] Numeric Literal Separator
On 28/05/2019 20:24, Dan Ackroyd wrote: I also happen to think people should only vote no if they think the change is something that adds too much complexity to PHP's internals for the change to be worth it I see where you're coming from with that, but there is also a cost to *users* in having more variants and complexity in syntax to understand and be tripped up by, even if it actually mad the internals simpler for some reason. I don't personally think that applies here, but it's a reason someone voting might decide to consider. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Proposal for a RFC
On Mon, 13 May 2019 at 19:55, Steven Wade wrote: > I'm personally unconvinced of the value of this, and would probably propose > it was blocked by coding standards in my team if it was added, because its > meaning is so ambiguous. > > > That's perfectly reasonable. Do you also block use of casting to a string > with (string) $foo as well? I ask because this proposal is simply on par > with the idea behind string casting for objects. > I have seen valid uses of __toString(), but I would certainly approach it cautiously. For a complex object, it's not at all obvious if (string)$foo will give you a debug representation, a JSON serialisation, an HTML rendering, etc. > Most objects do not have a single "natural"/"canonical" array > representation > > > I think the same could be said about "__toString()". But with that, some > classes can be boiled down to a single representation, such as the > Ramsey\Uuid <https://github.com/ramsey/uuid/> package. > Indeed it could. I think the difference is that a "one-dimensional" object, like a UUID, probably does lend itself to a single canonical string representation. You wouldn't expect it to return XML, or JSON, or any other string format, so (string)$uuid is fairly unambiguous. > The same is with arrays. You can have a single entity such as person to > where its array representation can be first name, last name, age, race, > gender, email, etc..., > This is exactly the kind of place I would *not* want a simple toArray() function. Should (array)$person (or $person->toArray()) return ['firstName'=>'Rowan', 'lastName'=>'Collins'], or ['name' => 'Rowan Collins'], or ['name' => ['Rowan', 'Collins']]? What date format should 'dateOfBirth' be formatted to? If 'address' is an object, should that be converted to an object as well, and into what format? The answers to these questions are going to be different in different contexts, and it doesn't make sense for the Person class to determine the "one true array representation" - the only canonical representation is the object itself. > or you can have a collection of items, to where in that representation as an array, you have control over what information is returned and what isn't. This is a more reasonable case; given that objects can't completely mimic arrays, I can see value in a custom List class implementing an array cast as a quick "back door" for using existing array functionality. > As a thought experiment, imagine a similar method which allowed you to > overload (object)$foo. Although (array)$foo tells you slightly more than > that, I'm not convinced it tells you enough that you're not just hiding > meaning behind cute syntax. > > > I'm confused by example, as there's no real need to overload casting to an > object as a class is already an object. Whereas, a class is not already an > array. > Sure, it's extra vague because "return $this" would be a valid response, but imagine there was something other than objects - structs, or custom resources, or whatever - and there was special syntax to say "give me an object based on this thing". The immediate question would surely be "what object? what are you using it for?" I feel the same way about "give me an array based on this object" - it tells me very little about what you actually want, and why. > It's not about "cute syntax", it's honestly about providing a simple > clutter free helper for developers to take control over how their classes > are transformed to array representations. > If it's not recursive, it's just syntactic sugar - which can be fine, if it serves a common use case, but it adds an extra "trick" that readers need to know about. It doesn't let you do anything you can't already - (array)$foo would just be a funny way of spelling $foo->__toArray() > JsonSerializable actually suffers from similar problems, and is IMO useful > only because it's automatically recursive. I presume the proposed mechanism > would not be, i.e. return [$foo] would not be interpreted as return > [(array)$foo]. > > > You bring up a good point. Could you for a moment pretend like you're > behind this proposal and expand upon this question? If PHP were to have a > __toArray() method, would you see it as being recursive? In your opinion, > how should/would it react? > A recursive method would certainly have more value, because it actually does something more than translate one syntax to another. On the other hand, the use case that comes to mind is serialization, and we already have more specific methods and systems for that. I guess that's what it comes down to, what *specific* use cases would this feature be intended to help with? Is there some code of your own that inspired you to propose it, or something you've seen publically that would benefit from it? Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV] Re: Proposal for a RFC
On Mon, 13 May 2019 at 14:46, Steven Wade wrote: > > Hi all, I wanted to re-ping the list to see if there is any more feedback > on this proposal? Any technical concerns or true BC changes? > I'm personally unconvinced of the value of this, and would probably propose it was blocked by coding standards in my team if it was added, because its meaning is so ambiguous. I actually see quite a lot of classes with normal methods called things like "toArray", and my comment is always "to *what* array?" Most objects do not have a single "natural"/"canonical" array representation, and such a transform is usually actually used as part of some particular helper or code pattern - e.g. an intermediate form for serializing to XML/JSON, or a compatibility-wrapper for legacy code. There's nearly always a better name for the method that properly indicates its intent. As a thought experiment, imagine a similar method which allowed you to overload (object)$foo. Although (array)$foo tells you slightly more than that, I'm not convinced it tells you enough that you're not just hiding meaning behind cute syntax. JsonSerializable actually suffers from similar problems, and is IMO useful only because it's automatically recursive. I presume the proposed mechanism would not be, i.e. return [$foo] would not be interpreted as return [(array)$foo]. Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV] open_basedir?
On Tue, 7 May 2019 at 11:38, Zeev Suraski wrote: > - especially here, where folks who rely on it for (even some level of) > security would have a lot of work on their hands to come up with a > different solution for isolation. > This point is worth dwelling on I think: if someone is using this feature as part of their security right now, is it better than nothing? I don't think it's sensible to assume that everyone seeing the deprecation notice will immediately put into place a security review of their hosting, so we should consider which of the following will lead to the best security outcome: a) open_basedir remains available, and people keep using it b) open_basedir is removed in PHP 8, and people upgrade without reviewing the rest of their security c) open_basedir is removed in PHP 8, and people stay on PHP 7.4 instead of upgrading If scenario (a) gives even a slight security advantage over scenario (b), we should think very carefully before removing the feature. Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV] Re: [RFC VOTE] Unbundle ext/interbase
On Thu, 2 May 2019 at 14:57, Christoph M. Becker wrote: > Indeed, it seems that pdo_firebird requires to connect to an existing > database, contrary to e.g. pdo_mysql which supports DSN like > `mysql:host=localhost`, to my knowledge. > Postgres works the same way - a connection is always to a single database, so you cannot have a DSN which doesn't specify one. Default installations now ship with an empty database called "postgres" to run administration commands like "CREATE DATABASE" on. Glancing that the ext/pgsql and ext/pdo_pgsql tests, though, it looks like we just require the user to have run "createdb test" before running the test suite. Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV] Revive Number Format Separator RFC
On 27 April 2019 13:51:11 BST, Lester Caine wrote: >On 27/04/2019 13:37, Rowan Collins wrote: >> The only way I've seen dates stored as integers is as a number of >> seconds / milliseconds / whatever since some epoch, most commonly >> seconds since 1970-01-01 00:00:00 UTC > >Use of a days count rather than a seconds count makes dates a lot >easier >to work with. 2 32bit numbers give a substantial day count along with >either fractional time of day or alternatively a second count for the >day. That makes sense, but it's still a variant on the epoch + count concept, not year-month-day as in Bishop's example. As such, it still wouldn't particularly benefit from separators; you'd probably write constants in string form and convert them on the fly, or have durations which were multiples of 7 or 365 rather than powers of 10 or 16. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Revive Number Format Separator RFC
On 27/04/2019 12:18, Thomas Punt wrote: Storing dates in an integer format can be a valid use case if performance is a concern. It is far faster and more compact to store and compare integer-based dates than using objects for everything. The only way I've seen dates stored as integers is as a number of seconds / milliseconds / whatever since some epoch, most commonly seconds since 1970-01-01 00:00:00 UTC The format Bishop seemed to be suggesting would be absolutely useless for anything other than the simplest comparisons: how do you add a day to the date-as-number 20190430? I'm sure there are use cases for this syntax, but the examples in that e-mail were poorly chosen. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Revive Number Format Separator RFC
> > On Thu, Apr 25, 2019 at 6:07 PM Theodore Brown
> > wrote:
> >
> >> Is there any chance the Number Format Separator RFC [1] could be revived
> >> for PHP 7.4? I looked at the discussion from a few years ago and it's
> not
> >> clear why many people originally voted against it.
>
Hi,
I'm not particularly against this proposal, but I'm not sure how often I'd
use it.
On Fri, 26 Apr 2019 at 06:15, Bishop Bettini wrote:
A cursory scan of current usage suggests that number format separator might
> be used in scenarios such as:
>
> Phone numbers
> 919_555_1234
> 49_89_636_48018
>
This is a poor example, because phone numbers shouldn't be stored as
integers; there's nothing you can do with them mathematically, and outside
of North America it's extremely common for them to have significant leading
zeroes.
> Date time values
> 2018_04_26
> 20180426_183242
>
Again, I can't see why you'd ever use an integer for that, rather than a
string. Were there really integer literals of this form in the packages you
searched?
> For those first few, Kotlin has similar examples [2], but Javascript
> discourages use of number separator in "number-ish" values (eg phone
> numbers) [3].
>
The second article you link to isn't official documentation, just someone's
blog post about the feature. I agree with the comment, though - the Kotlin
example of a credit card number wouldn't pass code review with me, because
they're not really "numbers", they're identifiers which happen to only use
digits (the only mathematical operation on a card number would be checking
the Luhn checksum, which is a digit-by-digit operation anyway).
The only example that I can see myself using is the one of money-as-cents
(or, in my case, pence):
$pricePence = 1000_00; // GBP 1000.00
Although some kind of struct with separate fields and overloaded operators
would probably be better still:
$price = Money{ 'GBP', 1000, 00 };
The main use I've had for large number literals is for things like cache
lifetimes, where the extra syntax wouldn't help, but constant expressions
do:
$lifetimeSecs = 604800; // 7 days
const SECONDS_IN_MINUTE = 60;
const SECONDS_IN_HOUR = SECONDS_IN_MINUTE * 60;
const SECONDS_IN_DAY = SECONDS_IN_HOUR * 24;
$lifetimeSecs = 7 * SECONDS_IN_DAY;
Similar approaches work for other contexts, for instance:
const GIBIBYTE = 1024 ** 3;
const GIBIBYTE = 2 ** 30;
both read more clearly than anything you could do with underscores:
const GIBIBYTE = 1_073_741_824;
const GIBIBYTE = 0x40_000_000;
const GIBIBYTE = 0b1_0_0_0_0_0_0;
Regards,
--
Rowan Collins
[IMSoP]
Re: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2
On 13 April 2019 10:09:20 BST, Stijn Peeters wrote: >Is anyone aware of other arguments for not allowing normal arguments >after >unpackable arguments in function calls? CHU Zhaowei pointed to this git commit which suggests it's an implementation issue rather than a design decision: https://github.com/php/php-src/commit/d3b484df8268f7ab31c4ac39734d4b68ce2e6159 From Nikita's excellent commit message, it sounds like normal parameter passing is compiled in an optimised way that wouldn't be safe if run after a spread operator was expanded. Rather than adding a whole bunch of complexity, the edge case was just made into a documented limitation. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Arrow functions / short closures
On 10 April 2019 21:56:41 BST, "Björn Larsson" wrote: >Could then the \($x) syntax be a good compromise between >readability & implementation? Personally, I don't find it "more readable"; on the one hand, it's one character shorter; on the other, it stands out less from everything else. My personal bias against it is that I'm too used to reading \ as "escape", so every time I see examples my first reaction is "what does an escaped parenthesis mean?" I'm sure I'd get used to it, but I prefer "fn" because it more immediately makes me think "function". Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Arrow functions / short closures
On Wed, 10 Apr 2019 at 09:59, Robert Hickman wrote: > > I'd just like to amplify this mention of 3rd party tooling: if we go with > > something which requires complex lexer/parser rules, then every editor, > > IDE, and static analysis tool will need to also work with that syntax. > > > > Is this actually a problem? Don't these tools make use of existing > parsers like 'php parser', thus the cost is lower than initially > apparent? > I don't think you can generalise about "these tools" at all - for instance, PHPStorm is written in Java, and VSCode is written in JS; I doubt they share any parser components with each other, or with anything written in C or PHP itself. We're not just talking about existing tools, either, but every tool created until the language dies. Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV] Re: [RFC] Arrow functions / short closures
On Tue, 9 Apr 2019 at 11:20, Nikita Popov wrote: > The ==> syntax is the other one I implemented ( > https://github.com/php/php-src/pull/3945). The implementation is based on > lexer lookahead, which is ugly but still manageable. I haven't seen much > support for this variant in this discussion though. And of course, if > there's no strong preference for ==>, I'd rather go with the variant that > is easier for us (and all 3rd party tooling) to support from a technical > perspective. > I'd just like to amplify this mention of 3rd party tooling: if we go with something which requires complex lexer/parser rules, then every editor, IDE, and static analysis tool will need to also work with that syntax. For those saying they "slightly prefer" ==> please ask yourself, do you prefer it enough to add complexity to every tool that wants to process PHP source code? Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV] [RFC] Deprecate left-associative ternary operator
On Tue, 9 Apr 2019 at 11:19, Bishop Bettini wrote: > See also Bug 61915[1], which suggests leaving ? left and introducing ?? for > right. Personally I don't see any benefit to keeping a ternary with left > associativity. > ?? wouldn't work, because that's now the null-coalescing operator. (I've no idea if it would be ambiguous to the parser to have it mean both, but it would be horrible for humans to read!) Obviously, that doesn't rule out having a new syntax of some sort, but it highlights the usual problem with suggesting new operators: we're running out of punctuation! Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV] [RFC] Deprecate left-associative ternary operator
On Tue, 9 Apr 2019 at 10:54, Nikita Popov wrote: > Hi internals, > > Inspired by Bob's recent RFC for concat precedence, I'd like to propose a > deprecation and removal of the left-associative behavior of ternaries. > Instead, explicit parentheses should be used: > > https://wiki.php.net/rfc/ternary_associativity > Thanks for putting this forward, it removes one more WTF from the language. I think non-associativity is safest, because even if it's rarely desirable, code may be out there that works accidentally with the current situation. There's also the risk that someone would get used to it working one way in PHP 8, and accidentally use it in code that's still deployed on PHP 7. In both cases, it's better to generate an error and force users to be explicit than introduce subtle bugs. We can then look at making it right-associative in PHP 9, because anybody that needs to support 7, 8 and 9 can be explicit, and hopefully not many people will be jumping directly between 7 and 9. Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV] bool values and increment operators?
On 07/04/2019 17:08, CHU Zhaowei wrote: In addition, I'm thinking whether it's possible and necessary to add a global strict mode (like "use strict" in js) in PHP 8 to deal with this kind of unexpected surprise. I know we have declare(strict_types=1) but it only works for functions and it's limited to call from current file. I'm not a fan of a generic "strict mode" the way JS has it, because it only works once: if you add more behaviours later, the BC break is just as bad as if the switch wasn't there. I wonder if in 10 years time, someone will propose a "use stricter" mode. Perl's "pragma" system is more flexible, and notably works at the file or block level, like PHP's declare statements. The most common pragmas are "strict", "warnings", and "feature", each of which has a set of sub-categories which can be individually enabled and disabled. You can also opt into all features as of a particular version (and require that version), again within a single lexical scope. The downside is that this leads to a lot of different combinations, in keeping with the Perl motto of There More Than One Way To Do It. The big downside of all this is that even if the compiler understands what all the combinations of flags will do, the human reading the code won't necessarily, so having declare(increment_warnings=1) probably doesn't add much over just documenting the change somewhere. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Parameter skipping
On 07/04/2019 11:53, Morgan Breden wrote:
>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.
Yes, that's what I meant by "automatically supported on existing
functions". The problem I was highlighting is that right now, I can
write this in version 1.0.0 of a library:
function foo($id) {
$blobId = $id;
doSomething($blobId);
}
And change it to this in version 1.0.1, without violating SemVer:
function foo($blobId) {
doSomething($blobId);
}
The name of the parameter is an implementation detail, not a contract.
If named parameters are automatic, that suddenly becomes a breaking
change, and either every library author recognises that and avoids such
changes, or every library user has to check documentation to see if it's
safe to use named parameters.
Worse, as highlighted in the 2013 RFC, parameter names aren't checked
when over-riding a method, like this:
interface Fooable { public function foo(int $id); }
class Blob implements Fooable { public function foo(int $blobId) { ... } }
So either the first version of PHP to support named parameters would
require library authors to change any such code, or again the library
user has to check if it's safe to use named parameters.
The alternative is to make named parameters opt-in on the part of the
function author, using extra syntax in the function declaration. I think
that's a better approach, but probably means an even longer wait until
libraries introduce it.
So realistically, even if named arguments were added right now, they
couldn't reliably be used to skip over default parameters in existing
functions.
None of this is a problem with a simple "default" keyword, which would
work reliably with all existing function signatures where a default is
defined, and require no change in code or practice on the part of
library authors, so can be introduced right now, and used straight away.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Parameter skipping
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] Question about adding !function_identifier
On Fri, 5 Apr 2019 at 14:05, Robert Hickman wrote: > > I think you're misunderstanding the problem: it's not that the > *programmer* doesn't know the types, it's that the *analysis tool* doesn't > know them, because the programmer hasn't told it, and currently has no way > to tell it. > > > > If the static analyser was programmable, it would be possible to > provide it such information, within the scope of a single code base. > I'm not really sure what you're suggesting; the normal way to "program" a static analyzer is to add more and richer type annotations to your code, as in the over-the-top example I gave (in reality, the analyser can deduce some of the types, and the syntax needn't be quite that ugly). The problem is that PHP has a lot of features where there is currently no way to specify types (callbacks, iterators, etc), and some where it's essentially impossible to do so in a checkable way ($$foo, $foo->$bar, etc). I'm not saying it's not possible, it's just a considerable project to rewrite a dynamic language into a statically typed one, and at the moment Hack is much further into that project than PHP, partly because it has less concern about backwards compatibility. Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV] Question about adding !function_identifier
On Fri, 5 Apr 2019 at 12:42, Robert Hickman wrote:
> In the first case:
>
> function foo(callable $bar): int { return $bar(); }
>
> I think the value of $bar would have to fall into a set of values
> known to the programmer, or at least known at some level.
I think you're misunderstanding the problem: it's not that the *programmer*
doesn't know the types, it's that the *analysis tool* doesn't know them,
because the programmer hasn't told it, and currently has no way to tell it.
To be confident the code was type safe, it would have to look like this:
function foo(callable): int { return $bar(); }
...and every call to it would have to be analysable back to a function
explicitly declared as returning int.
The same applies to exception checking: you'd need syntax for "accept any
callable that never throws", or "any callable that only throws descendants
of FooException or BarException".
Then you end up with this kind of fun:
function curryish(callable<(int, float): int throws
FooException|BarException> $callback): callable<(float): int throws
FooException|BarException> {
return fn($x) => $callback(42, $x);
}
Regards,
--
Rowan Collins
[IMSoP]
Re: [PHP-DEV] Question about adding !function_identifier
On Fri, 5 Apr 2019 at 11:30, Robert Hickman wrote:
> If a static
> analyser were programmable, it could parse the SQL query and query the
> database to find out what keys exist in some_table. Thus it could
> check for references to non-existing keys.
>
That's an interesting example, but I don't think it generalises as far as
you think: what would a "programmable analyser" do with an array of HTTP
headers, or query-string parameters?
However, I wasn't referring to dynamic *data* like this, but rather dynamic
behaviour in the language itself. A couple of simple examples:
function foo(callable $bar): int { return $bar(); }
function foo(iterable $bar): int { foreach ( $bar as $baz ) { return $baz;
} }
In order to analyse those, you need a) the language to offer a richer type
system (generics, derived types, etc); and b) the programmer to make full
use of that type system, everywhere.
As soon as you have code that's missing rich type information, or use a
truly dynamic feature, that whole section of code becomes essentially
unchecked. That's why Hack is not only adding features for richer
(statically analysed) type annotations, but also *removing* PHP features
which don't work nicely with them.
Regards,
--
Rowan Collins
[IMSoP]
Re: [PHP-DEV] Question about adding !function_identifier
On Fri, 5 Apr 2019 at 09:57, Robert Hickman wrote:
> >
> > For instance:
> >
> > function foo(): type nothrow {
> > throw new SomethingException;
> > }
>
> Would it be possible to analyse the call graph at compile time
> (bytecode generation) and then trigger a fatal error? It wouldn't be
> possible for variable functions/methods though. A separate static
> analyser could do the same thing.
>
Yes, I think we are rapidly approaching the limit where to make the
language stricter, we need an official static analysis tool, like Hack has,
rather than trying to do everything at run-time.
It might even be possible to build this into OpCache somehow, so that if
you pre-analyse your code, it will skip runtime checks that it can prove
will never fail (e.g. return type annotation on a function that always
returns literals).
The tricky part is that PHP is a highly dynamic language, so there's a lot
of cases where the analysis can only return "maybe". My understanding is
that this is what a lot of the work on Hack is doing: creating a language
which looks a lot like PHP, but doesn't have as many ambiguous cases which
can't be analysed statically.
Regards,
--
Rowan Collins
[IMSoP]
Re: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2
On Fri, 5 Apr 2019 at 09:31, Michał Brzuchalski wrote: > The next paragraph in MDN document is spread operator for object literals > https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_syntax#Spread_in_object_literals > Now JavaScript objects can be used like our array with keys and I simply > don't understand why we cannot preserve keys, like in JS object literals > The original draft discussed this, but there wasn't agreement on how identical keys should be handled, e.g.: $a = ['foo' => 1, ...['foo' => 2]] Should $['foo'] be 1 or 2? Cases were made for both, and it was pointed out that if we get named arguments, the argument spread operator will need to work the same way as whatever is decided for arrays. So the current approach is to get integer keys working first, using the same behaviour as for parameters, and then revisit string keys later. Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV] Question about adding !function_identifier
On 04/04/2019 16:17, Sara Golemon wrote:
I would say that any exception thrown in (1) should lead to an non-zero
exit since the program has violated an invariant assumption.
The problem with enforcing an exception contract at runtime is surely
how to avoid the cure being worse than the disease.
The behaviour most consistent with the current language would be to
throw an Error - this is what happens for other invariant violations
like "null passed where an array was expected". But that doesn't really
make any sense here: it would mean wrapping a meaningful exception in a
generic UnexpectedExceptionError and then throwing it again, at code
that's still not expecting it.
An immediate fatal error would be more practical, but I'm not sure what
benefit it would bring. If the calling code has no way of catching the
exception, it will eventually blow through the stack and become a fatal
error anyway; but if it would eventually reach a catch block, what value
is added by making it fatal immediately instead?
For instance:
function foo(): type nothrow {
throw new SomethingException; // or, more likely, fail to catch one
from a deeper call
}
function bar(): type throws ( SomethingException ) {
throw new SomethingException;
}
try {
foo();
bar();
} catch ( SomethingException $e ) {
log($e);
}
The program can clearly cope with a SomethingException and carry on; but
because the author of foo() didn't fully test their code, it has no
chance to and is killed outright instead.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2
On Thu, 4 Apr 2019 at 17:14, Derick Rethans wrote: > Could you add to the RFC what the exact pain point is that this is > trying to address? It looks a little like this is just adding syntax for > the sake of it. > Not everything is about pain, some things are just about gain. ;) The link Levi shared about Dart included some interesting examples of where spreads are useful, some of which you can probably imagine happening in PHP: https://medium.com/dartlang/making-dart-a-better-language-for-ui-f1ccaf9f546c It also takes us a step closer to having a short-hand for iterator_to_array, in the shape of [...$iterator]. On its own, that's still pretty ugly, but it's not hard to come up with cases where it would be a lot nicer, like concatenating two iterators: // Before array_merge(iterator_to_array($iter1), iterator_to_array($iter2)) // Or to generalise to all iterables array_merge( is_array($iter1) ? $iter1 : iterator_to_array($iter1), is_array($iter2) ? $iter2 : iterator_to_array($iter2) ) // After (handles both cases) [ ...$iter1, ...$iter2 ] Granted, I can't point to a real-life example of that, but it shows that this isn't just new syntax for something that's already easy. Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV] Question about adding !function_identifier
On 03/04/2019 20:31, M. W. Moe wrote: the commenting section suggestion was some kind of decoy or trap; it does not address the original request and its scope Perhaps you could clarify what that scope is, then. As I say, I'm not clear what the difference is between the proposed syntax and a comment, unless it changes the behaviour of the language in some way. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question about adding !function_identifier
On 03/04/2019 18:13, M. W. Moe wrote: > The argument sits there. > > function handle(int $cmd, ...$arg) : int /* throw */ > function !handle(int $cmd, ...$arg) : int The first example is unambiguous, easy to understand by anyone with a basic knowledge of the language, easy to spot when reading the code, easy to grep for, and will be recognised as a comment by any tool for parsing PHP. The second example is hard to spot, completely opaque in meaning, and would break any tool which didn't have it added as a feature. I'm really struggling to see any advantages at all, other than saving a few key presses. Of course, neither documents what type of exceptions will be thrown, so it's a bit like documenting every return type as either "void" or "mixed"; which is why the more common practice would look more like this: /** @throws InvalidFooException */ function handle(int $cmd, ...$arg): int you seems not having the experience of working on the same code base with basically literally dozen of people which can at some point intervene; this is reality, this not wrong or bad; you deal with it. You're right, I haven't worked in a team that size, but if I did, I would expect strict coding standards that emphasise clear intent and documented behaviour to be absolutely essential for everyone to know what was going on. either you enforce extra qualifiers in term of signature or you don't encourage it I'm struggling to see the difference between enforcing "add an ! before the name if it throws" and "add a comment next to the name if it throws", or even "add X to the name if it throws", unless the language itself is going to perform some extra check. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question about adding !function_identifier
On Wed, 3 Apr 2019 at 17:52, M. W. Moe wrote:
> not documenting at first is not really a question of laziness or so, as
> things are still moving around
> you absolutely need this agility; a good design layout between theory and
> stable state will refactored
> discussed a thousand times; that what I expect from engineers; filling the
> gaps between assumptions
> and reality.
>
I think we have different assumptions about what "documentation" means
here. I'm not saying you have to write a 500-word paragraph explaining the
theory and edge-cases in the code; just that you should write a quick
comment saying what the function expects, and what it will return, beyond
the ability of the language's syntax.
You *could* write every function like this:
function tbc(...$args) {
}
That way, you can change the visibility, the argument types, the return
types, and the name, without "documenting" it in advance. Clearly, that
would be ridiculous, so you probably actually write this:
public function convertFooToBar(Foo $foo): Bar {
}
What I mean by "documentation first" is to go a small step further and
write:
/**
* Convert using the lookup tables
*
* @param Foo $foo Should only be given pre-validated Foo
* @return Bar Will always be pre-validated
* @throws InvalidFooTypeException
*/
public function convertFooToBar(Foo $foo): Bar {
}
This is all part of the *current* design of this function. It might change,
but if it changes, you change the docblock, just as you'd change the
signature if you realised it should actually be private, or accept a
PreValidatedFoo object, or the name is wrong.
You seem to want to do this same job, but with as few characters as
possible, and I don't really understand why, if your aim is to be explicit
and clear. If you just want to type less, use an IDE or editor with good
auto-complete support.
Regards,
--
Rowan Collins
[IMSoP]
Re: [PHP-DEV] Question about adding !function_identifier
On Wed, 3 Apr 2019 at 17:27, M. W. Moe wrote: > yes this is very true; but usually on complex design with a lot of folks > working on it you start coding before documenting; > If it's just syntax that doesn't change behaviour, it's really just documentation anyway, and if people are so desperate to dig into the code that they can't write a minimal docblock (or so lazy that they won't), how likely is it that they'll correctly add this new indicator? If you want to be explicit, don't put off docblocks until later (writing them before you've even implemented the function can be a great way of clarifying your design), and use an IDE or CI tool that will tell you when they're missing or incorrect. Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV] PHP_FLOAT_MIN is positive
On Wed, 3 Apr 2019 at 13:33, Benjamin Morel wrote: > PHP_FLOAT_MIN (float) > > Smallest representable POSITIVE floating point number. If you need the > > smallest representable floating point number, use - PHP_FLOAT_MAX. > > Available as of PHP 7.2.0. > I'd avoid the word "smallest". PHP_FLOAT_MIN could be described as having the "smallest magnitude", and -PHP_FLOAT as being "the largest magnitude, but negative". Perhaps: > Closest representable positive floating point number to zero. If you need the > negative number furthest from zero, use -PHP_FLOAT_MAX. Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV] [RFC] Change the precedence of the concatenation operator
On 31/03/2019 14:50, Niklas Keller wrote: An alternative to prevent mistakes in this regard is making this a compile error and requiring parenthesis. If we're going to changes any precedence in the language, please please please can we look at the ternary operator associativity? I think making it non-associative, so that you have to use parentheses in "$a ? $b : $c ? $d : $e" would break very little code, in an obvious way, and help with a major pain point people have with the language. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP 8 Preview Releases
On Fri, 29 Mar 2019 at 14:18, Arvids Godjuks wrote: > Hello, > > I'd like to add that as the userland developer, it would be nice to be able > to build JIT against an active branch (a.k.a PHP 7.4), cause if PHP 8 > brings enough changes, it would not be realistic to fix our apps to be > compatible with PHP 8 months or years away from actual release. > This was the purpose of the secondary vote on the RFC ( https://wiki.php.net/rfc/jit#proposed_voting_choices). The result was 18 Yes to 36 No, so JIT will be PHP 8 only. I won't repeat the discussion here, see the original RFC thread for the pros and cons, and why I suggested a "PHP 8 Preview" would be a better target for people to test against. Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV] Re: [RFC] Permit trailing whitespace in numeric strings
On Tue, 26 Mar 2019 at 23:09, Benjamin Morel wrote: > Also, may I suggest that these 2 RFCs be merged together? > > https://wiki.php.net/rfc/string_to_number_comparison > https://wiki.php.net/rfc/trailing_whitespace_numerics > Although they are complementary, the two RFCs are tackling different subjects, so should remain separate IMHO. - Andrea's RFC is discussing the behaviour of parsing number strings in a wide variety of contexts, including implicit and explicit casts. - Nikita's RFC is discussing the specific case of comparisons, and applies existing number-parsing rules to different contexts I am certainly in favour of them both targeting PHP 8, possibly along with additional "type juggling" changes, which could all be documented together, but I think it would just be confusing to try to cover all the examples, pros and cons, and voting options in one RFC. Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV] Re: [RFC] Permit trailing whitespace in numeric strings
On 26/03/2019 21:54, Benjamin Morel wrote: I almost had a heart attack after running this code. I knew that PHP had a few quirks when comparing different types, but I had long taken for granted that comparing 2 *strings *performed a byte-by-byte comparison. You might want to have a stiff drink before reading through the examples in this RFC then: https://wiki.php.net/rfc/string_to_number_comparison Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bool values and increment operators?
On Mon, 25 Mar 2019 at 15:03, Christian Schneider wrote: > The documentation has a highlighted box stating > "Note: The increment/decrement operators only affect numbers and strings. > Arrays, objects and resources are not affected. Decrementing NULL values > has no effect too, but incrementing them results in 1." > The NULL part of that has always baffled me. Why should ++ not be symmetrical with -- here? In general, documenting what we currently do is great, but is separate from agreeing that it's what we *should* do. Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV] RFC Process: more productive conversations
On Mon, 25 Mar 2019 at 14:02, Dan Ackroyd wrote:
> On Mon, 25 Mar 2019 at 13:30, Rowan Collins
> wrote:
> >
> > One suggestion for an additional section: update the RFC with feedback,
> > particularly if it is withdrawn or rejected.
>
> I think that knowledge could live separately from the RFCs, which is
> why I'm maintaining https://github.com/Danack/RfcCodex
>
> The reasons for doing it separately are:
>
> * the last thing someone wants to do after having their RFC voted down
> is spending more time documenting it.
>
That feels pessimistic to me: is assumes that the author feels unhappy with
the RFC failing, rather than taking on board the feedback. You already have
a section headed "Don't be too put out if people don't like your RFC", and
I think taking on board why people disagreed is a big part of that.
> * some ideas have had multiple RFCs, while other ideas are proposed on
> the list without having a formal RFC. For both scenarios documenting
> why it failed in a single place needs to be elsewhere than an RFC
> page.
>
That's certainly an issue, which I've suggested before in the form of an
"Internals FAQ". However, it somewhat contradicts your previous point:
you're now asking someone to do *even more work* after an RFC is rejected,
to summarise it in a new format, in a new location. Either that's the RFC
author, or it's someone interested enough that they could offer to write it
in the RFC itself.
As RFCs re-raising previous ideas, they can and should link to and explain
their relationship to related RFCs, and this should probably be in the
guidelines if it's not already.
> > It has actually been suggested multiple times that
> > voters *should* justify their votes,
>
> Yes. However that is unlikely to provide a useful conversation.
> Thinking that the RFC is just a terrible idea is always a valid reason
> to vote no. Having people say that "this RFC is terrible" doesn't lead
> to a productive conversation.
>
That's because it's an unhelpful comment. What does "terrible" mean? Other
than "I assume you raised this in bad faith", there is *always* a more
productive explanation than that - "I don't think this fits the
style/purpose/scope of the language", "I think this would encourage/only be
useful for bad practices", etc.
> > so that it's clear whether a future RFC could address the
> > perceived problems,
>
> I don't believe forcing people to explain their votes actually does that.
>
Right, which is why I said I'm on the fence about *forcing* it, but that we
should at least *encourage* it.
> The problem with that is that some RFCs are just fundamentally not
> good and so there isn't any changes that could be made that would make
> the RFC acceptable.
>
> In those scenarios, putting pressure on 'no' voters to say what needs
> to be fixed, is just putting pressure on people to not vote no.
>
I don't think that follows. If the answer to "what would make you change
your mind?" is "nothing", that's still useful feedback - it tells future
RFC authors not to approach the suggestion at all.
> Additionally in some of the RFC discussions we've had, where the
> author has asked for people to explain the 'no' votes, the reasons
> have already been said clearly in the discussion phase.
>
Yes, the important thing is that the different reasons for no votes are
captured, not that the exact counts for each are tallied. It's also a
reason to add a text field to the voting widget: it doesn't invite
responses in the same way a post to the mailing list thread does.
I think a reasonable compromise is to say that voters should mention the
reasons they're voting no if they have not already been mentioned; but that
proposers should assume that votes without a reason are agreeing with
previously stated reasons. That discourages voters assuming proposers can
read their mind ("well, obviously it's bad") but also discourages proposer
pestering and cross-examining voters.
Regards,
--
Rowan Collins
[IMSoP]
Re: [PHP-DEV] RFC Process: more productive conversations
On Mon, 25 Mar 2019 at 13:04, Dan Ackroyd wrote: > I've written some suggestions on people could have more productive > conversations which I'm going to maintain here > (https://github.com/Danack/RfcCodex/blob/master/rfc_etiquette.md), and > have attached to the end of this email. > Hi Dan, Thanks for putting this together, I think it's a great addition to the current RFC guidance. The only part I can see being controversial is this: > It isn't the responsibility of voters to explain why they're voting no. It has actually been suggested multiple times that voters *should* justify their votes, so that it's clear whether a future RFC could address the perceived problems, or if similar RFCs are likely to receive the same votes against. I'm on the fence whether making it a hard requirement is reasonable, but I don't think we should enshrine the opposite. One suggestion for an additional section: update the RFC with feedback, particularly if it is withdrawn or rejected. If someone comes along with a suggestion that's been discussed before, it's really helpful if we can say "see this page for why it didn't happen last time, and see if you can fix those issues", rather than just "it didn't get very far before, but we can't remember why". This is something I intend to do with my own "locked classes" RFC: I'm probably going to withdraw it because I don't have time to rework it, but will try to summarise where a new RFC could pick things up. Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV] [RFC] Unbundle ext/interbase
On 24 March 2019 11:33:45 GMT+00:00, Lester Caine wrote: > problem then is that PHP7.4 >essentially becomes a nogo zone because there is no way to remove the >deprecation warnings Presumably the PECL extension, with no deprecation warnings, could be set up straight away, and builds offered for PHP 7.4. That way, the deprecation notices are immediately actionable, and the new home of the extension gets more publicity. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] JIT
On 23 March 2019 19:46:16 GMT+00:00, Peter Kokot wrote: > I'm sure very little people will compile PHP 8.0-dev on >their own and install it to test that before the release. I suggested before that a series of official PHP 8 preview builds could be released so that people didn't need to compile their own, and I believe somebody offered to do so. The trade-off then is between testing an up to date JIT (as opposed to one snapshotted when 7.4 ships, with limited updates) and being able to test the JIT without fixing deprecation notices (but possibly encountering bugs already fixed for 8.0). Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Unbundle ext/interbase
On 23 March 2019 21:09:35 GMT+00:00, Kalle Sommer Nielsen wrote: > the extension can be taken over by anyone who >wants to from the relevant community, it just will not be distributed >by default with PHP. In fact if the extension is released on PECL, it >gives the relevant community more freedom to deal with the extension >as they deem fit and does not have the strict requirements as >extensions in the Core has. Sources and binaries are still available >with the PECL interface. It's probably worth noting the example of Microsoft SQL Server here: the previous PHP extensions were dropped from the core in 7.0, and Microsoft now manages an open-source, cross-platform extension, and is able to release it as often as they want, and bring in features and bug fixes to encourage its use: https://github.com/Microsoft/msphpsql For an extension connecting to any actively developed third-party system, this is probably actually the best model, with PHP Internals experts providing advice where necessary, and third-party experts tracking innovations in the particular system. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC Draft: Comprehensions
On Thu, 21 Mar 2019 at 15:21, Robert Hickman wrote:
> In this case nextIf() would have to be implemented something like:
>
> function nextif($someCondition) {
> foreach($this->iteratorValue as $x) {
> if( yield $x;
> }
> }
> }
>
> iterator_to_array would need an internal loop to pull the values from
> the generator.
I think it would be more like this:
function nextif($someCondition) {
do {
$this->currentIndex++;
$x = $this->items[ $this->currentIndex ];
} while ( ! some comparison of $x and $$someCondition);
return $x;
}
nextIf() wouldn't be a generator, it would be a normal function returning
one value.
There is a nested loop in that imaginary version, but only because you
can't indicate "don't return anything"; given we're in imaginary concept
land, we could add that, and all sign of inner loops disappears:
function nextif($someCondition) {
$this->currentIndex++;
$x = $this->items[ $this->currentIndex ];
if ( some comparison of $x and $$someCondition) {
return $x;
} else {
return SKIP_THIS_ITEM;
}
}
> Thus, as far as I can see, the generator implementation
> would result in two loops running in lock step, rather than only one
> in the eager case.
>
It's more like a pipeline: there's a single loop pumping data in, and at
any time there's a single "current item", which is either being checked
against the condition, manipulated in some way, or passed out the other
end. Each stage in the pipeline doesn't need to track what "current item"
means, it's given an input each time the loop cycles.
We write that as "foreach ( $previousStage as $x ) { yield $x; }" because
it's a familiar syntax, but really we're just defining the logic for a
nextStep($x) function.
Regards,
--
Rowan Collins
[IMSoP]
Re: [PHP-DEV] RFC Draft: Comprehensions
On Thu, 21 Mar 2019 at 11:00, Robert Hickman wrote:
> I was only making a point for where a non-generator version of
> comprehensions could be useful, under the premise "Therefore, a
> lazy-evaluating syntax is more powerful, in that it can do everything
> an eager-evaluating one can do *and more*.". This implies that it
> dosn't have any downsides, whereas performance may be a downside.
>
Ah, OK, I see where you're coming from. I'm no expert, but I'm not sure how
much difference it would actually make.
Whether the comprehension is eagerly evaluated internally, or by a call to
iterator_to_array, the input will always need to looped over exactly once,
with each element being tested against the condition and run through the
output mapping.
A manual eager implementation (with no output mapping, for simplicity)
would look like this:
foreach ( $array as $element ) {
if ( someCondition ) $newArray[] = $element;
}
Which is basically equivalent to this:
while ( $element = $arrayIterator->next() ) {
if ( someCondition ) $newArray[] = $element;
}
A lazy implementation just moves the if check into the iterator; it might
look like this:
while ( $element = $filteredArrayIterator->next() ) {
if ( someCondition ) $newArray[] = $element;
}
But $filteredArrayIterator->next() is actually $arrayIterator->next() with
a built-in if check, so you could also picture it as doing this:
while ( $element = $arrayIterator->nextIf ( someCondition ) ) {
$newArray[] = $element;
}
So the underlying operations are the same, they just happen in different
orders.
The only real difference I can see is that under a very specific set of
circumstances, it could be compiled into a tight loop on the CPU. It would
require a JIT to check all of the following held, though:
- The input is a plain array, not any other iterable
- The condition can be inlined (e.g. not a function call like "if (
checkSomething($x) )")
- The output mapping can be inlined (e.g. not a function call like "yield
doSomething($x)")
Returning a generator by default just requires an extra check in that list:
- The expression is contained within iterator_to_array (or whatever syntax
shortcut we come up with for that).
I might be wrong, though, in which case this would indeed be an argument in
favour of having a dedicated array-returning syntax, either alongside or
instead of a generator-returning one.
Regards,
--
Rowan Collins
[IMSoP]
Re: [PHP-DEV] RFC Draft: Comprehensions
On 21 March 2019 00:39:20 GMT+00:00, Robert Hickman wrote: >For my use case of PHP, get some content from a DB and dump it into a >template, I don't see much benefit to generators. With respect, so what? I never said that every use case benefits from generators, nor are we discussing whether generators should be added to the language. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC Draft: Comprehensions
On 20/03/2019 20:39, Stanislav Malyshev wrote:
Hi!
It's not that you can't make an array into a generator, but you can't make
an eagerly-evaluated expression into a lazily-evaluated one.
Not sure what you mean here.
I mean that, given a syntax that lazily-evaluates something, you can
"fast-forward" the result to make it eagerly-evaluated; given a syntax
that eagerly-evaluates something, you cannot do the opposite. Therefore,
a lazy-evaluating syntax is more powerful, in that it can do everything
an eager-evaluating one can do *and more*.
In this particular case, when you're working with an iterator over a
large file, you probably want a generator. Which is very easy to write
using a functional syntax, and the only thing comprehension syntax does
is switching the parts around a bit and saving you writing a "function"
keyword. I don't think it's a very common case though.
Isn't that true of *every* use of the syntax, though, that "all it does
is switch the parts around a bit"? There's nothing that an array
comprehension can do that can't be done any other way, it's just
short-hand; making it return a generator just extends that short-hand to
more use cases.
Of course, when you need to filter iterators, then you need a different
approach. I do not doubt that. I doubt that filtering iterators is the
most common case in PHP to make the comprehension syntax only support it
- I think the case of array transformation is much more common.
I am not saying that it is "the most common case", and I am not saying
that it should be the only thing supported. I am saying that if we don't
have dedicated syntax for each, one way to support *both* variants is to
make the iterator version the base case, and then have a universal
syntax that switches it to an array.
If we do have syntax for both variants, then clearly both cases are
covered anyway - although I think a short-hand for iterator_to_array
would still have merit elsewhere.
But if we only have one, it should be the iterator version, with a
short-hand for iterator_to_array as a separate language improvement.
I think this would significantly reduce the usability of such construct
- to the point that it's easier to use the existing syntax, thus making
new syntax sugar useless. The whole point of syntax sugar is making
common case easy, and doing what you are suggesting is to make a corner
case (existing, but IMHO much less common) easy and make the user work
to achieve the common case.
I think you're arguing against a straw man here. Yes, the cost of the
extra syntax should be weighed against the benefit of the extra
flexibility. And IF the extra syntax was so verbose that it would be
easier to use the existing syntax, that cost would probably be too high.
But that's not what I was suggesting at all; I was picturing a new
operator, a few characters long, which could turn any iterator into an
array.
Are you really saying that something like this:
$a = [ ... (foreach $x as $y if $y < 2 yield $y) ];
would be so verbose that you'd rather write this:
$a = (function() use ($x) { $a=[]; foreach ( $x as $y ) if ( $y < 2 )
$a[] = $y; return $a; })();
or with the shortest closure syntax I can think of, this:
$a = (() => { $a=[]; foreach ( $x as $y ) if ( $y < 2 ) $a[] = $y;
return $a; })();
By all means let's try to weigh the cost and benefit, but let's not jump
to the conclusion that the cost is nearly infinite and the benefit is
nearly zero.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
