Re: [PHP-DEV] Proposal: Binary type for PDO
On Fri, 7 Jul 2023 at 18:39, Calvin Buckley wrote: > > I'd like to hear any oversights, and what could be done to take this > further. I think someone needs to write some code and some tests, and see what happens. It's possible that PARAM_BINARY could be used across all of the PDO drivers that PHP ships with, and for each of them the behaviour with that option is sensible. It's also possible that the behaviour of binary parameters is bespoke to each of the drivers, and that it isn't possible to use PARAM_BINARY in a DB agnostic way. The most realistic way to find out which option is more real, is to write the code + testswhich would need to be done anyway, even assuming the best case scenario. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Request karma privileges to vote on PHP RFCs
On Tue, 4 Jul 2023 at 20:30, Nuno Maduro wrote: > > Hi Internals, Hi Nuno, > I believe having a Laravel core team member on the list of members with > voting rights would be incredibly valuable to the internals team. All open source projects value contributions to their project really highly compared to pretty much everything else. There is nothing stopping you spending time and helping to improve RFCs or fix issues. You don't need any karma or permission to do that. > I have a strong connection with the Laravel community, I think presenting the voice of a large number of downstream users would be useful. Instead of giving a personal vote for yourself, how about we*, the PHP project, think about setting up a vote for the 'Laravel project' as a voting entity? The idea being, your users can come together and give feedback as a single voice, in some public source the Laravel project publishes e.g. laravel.com/net.php.wiki/rfc/some_rfc_name/feedbackrather than having the whole burden of interacting with internals be solely on yourself. I've been meaning to say some stuff about communication between internals contributors and downstream users for a while now. I'll try and finish that email, but I think setting up something like that, would be a better path than the one we're currently on. To note, it will probably take some time to figure this out. I'm reasonably sure people will have opinions. Possibly quite a few. cheers Dan Ack * not that I actually am the PHP project, but I'm probably part of it. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] [VOTE] PDO subclasses
Hello internals, I'm opening the vote for the 'PDO driver specific sub-classes' RFC: https://wiki.php.net/rfc/pdo_driver_specific_subclasses It will last for two weeks and end on 2023-07-17T17:00:00Z cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] PDO Subclasses coming to vote soon.
On Thu, 29 Jun 2023 at 11:40, BohwaZ wrote: > > I'm sorry to disagree, but changing this would be a bad idea for > security. > > I'm quite sure that I never want users to be able to load any > extension through SQL, or it would mean trouble :( > > So just like in the SQLite3 extension, extension loading should be > limited to using the PHP method, not SQL. Yes? I think you possibly misread my email. Danack wrote: > > As that means that SQLite extensions can only be loaded through C code > (not through SQL), aka the Sqlite people improved the api around extension loading since it was implemented in the Sqlite3 extension https://www.sqlite.org/c3ref/load_extension.html So the only way to load an extension would be through the PHP loadExtension method, it wouldn't be possible to load one through SQL. > it would be great to also have Sorry, I am in too much pain to look at those before the deadline. There is always 8.4 https://www.youtube.com/watch?v=wccRif2DaGs . cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] PDO Subclasses coming to vote soon.
On Tue, 27 Jun 2023 at 17:25, Larry Garfield wrote: > > The RFC doesn't specify if `new PDO(...)` changes behavior at all. That behaviour is not changed at all. > will PDO still have the postgres methods Yes, until someone does another RFC to deprecate and remove them. > if someone does [`new PDO(...)`], will they now get back `PdoPgsql`, No. New`ing one object, and getting a different object back would be far too surprising to even be contemplated. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] PDO Subclasses coming to vote soon.
Hi everyone, Just giving an update on the https://wiki.php.net/rfc/pdo_driver_specific_subclasses RFC as time is running out. The RFC text has been updated with the implemented subclasses stubs. There are a few small things to note, and one larger thing: Marc Bennewitz wrote: > It would be great if driver specific constants would be added to the driver specific sub-classes without the driver name repeated in the const name. Okay, that will be done before it goes to vote. It probably has a downside of making there need to be a large duplication of tests, rather than being able to re-use the existing tests, but I guess it's probably worth doing. >> Create all DB sub-classes? > > yes please k. That has been done. Rowan Tommins wrote: > but as a minimum there should be an internal API for > registering a sub-class, without any modification to ext/pdo. There is now. The larger issue is whether to add an ini setting for SQLite extension loading or not. The sqlite3 PHP extension has an ini setting which limits extensions to be loaded from a particular directory, presumably as a safety precaution. The Sqlite3 extension uses the code: sqlite3_enable_load_extension(sqlite_handle, 1); which affects both the C api and loading extensions through SQL code. However, in the proposed PdoSqlite class this code: sqlite3_db_config(db, SQLITE_DBCONFIG_ENABLE_LOAD_EXTENSION, 1); is used to temporarily enable extension loading, which only enables it through the C api. As that means that SQLite extensions can only be loaded through C code (not through SQL), and if someone can upload and execute code to your server, your server is compromised anyway, having to edit ini files to enable extension loading, seems like a bad tradeoff. Thoughts? cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] RFC [Discussion]: Closure self-reference
Hi internals, I'm now opening the discussion for the Closure self-reference RFC: https://wiki.php.net/rfc/closure_self_reference This was previously discussed as a draft here: https://externals.io/message/112216#112216 Thank-you to KapitanOczywisty for the implementation. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC [Discussion]: Marking overridden methods (#[\Override])
On Mon, 22 May 2023 at 22:32, David Gebler wrote: > > either you use static analysis tools as part of your PHP workflow, because > you care about that stuff, or you don't. I these words imply an unpleasant connotation; that people who don't use static analysis tools are bad people who don't care about their code. Just because someone doesn't use the same tools that 'good' programmers who care about their code use, doesn't mean that they 'deserve' to be punished for doing not having having setup those tools*. > I would argue means any new runtime check > warrants the utmost consideration of cost-benefit. The Override annotation is a small thing that we can add to PHP, that has a very low cost, and would benefit programmers who haven't had enough time/experience to setup static analysis tools. It appears to be a 'positive sum' proposal. Or as Ilija Tovilo wrote: > > The benefits seem worth the maintenance cost, even if small for the > average user. cheers Dan Ack * At least in this case, because having to deal with code that uses inheritance is already punishment enough. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC [Discussion]: Marking overridden methods (#[\Override])
On Sat, 20 May 2023 at 18:58, David Gebler wrote: > > this is exactly the kind of check which you would > expect to be done at the static analysis stage Even for those who use static analysis, most (afaik) don't have it running constantly in local development and this RFC would prevent people wondering why their code is behaving surprisingly before it is static analysed. Also, not everyone uses static analysis tools. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC [Discussion]: Marking overridden methods (#[\Override])
On Thu, 18 May 2023 at 09:12, Marco Pivetta wrote: > > I am not sure this RFC is really relevant... Would it perhaps > make sense to have this in userland first, in phpstan or psalm > plugins, to see if there is interest? The RFC lists other languages where an equivalent is available, and we can see that it appears quite popular: https://stackoverflow.com/questions/94361/when-do-you-use-javas-override-annotation-and-why https://github.com/microsoft/TypeScript/issues/2000 In those languages, it is a recommended "defensive programming" (https://ocramius.github.io/extremely-defensive-php/#/23) technique, that protects against the types of mistakes that are listed in the RFC. So one should be able to see there is interestunless of course someone is so bad at basic human empathy, that they can't accept other people's lived experiences as valid, and will only accept something as 'good programming practice' if they have invented or experienced it themselves. But if that's the case, there's no use trying to persuade them. All you can do is point out that habit of not liking things that they haven't yet used/invented themselves, and hope that other people don't spend too much time arguing with someone who has a pattern of being unreasonable. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] rounding integers
On Sun, 21 May 2023 at 06:16, Marc wrote: > > Do you think this could be an acceptable BC-break No. Suggesting changing a 30 year old maths operations is a huge BC break. > or should this be a different function? Just make your own that does precisely what you want... cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC [Discussion]: Marking overridden methods (#[\Override])
On Thu, 11 May 2023 at 17:37, Tim Düsterhus wrote: > > Hi > > I'm now opening discussion for the RFC "Marking overridden methods > (#[\Override])": > > I'm now opening discussion for the RFC "Marking overridden methods > (#[\Override])": This RFC is probably a good idea, even if the number of people who will benefit from the behaviour in the engine might be quite low. My guess is the number of people who will bother to write those attributes, and who also won't bother to setup CI, is quite small. But, this RFC another step forward from where we are, to having 'too many' attributes/annotations, so I have a question. How do we stop prevent ourselves from copying the problems that Java has made for itself? Or putting it another way, is it possible for us to set any guidelines on what annotations are 'good' or 'bad' ? I hope I am at least consistent with my concerns about annotations. Danack wrote in https://externals.io/message/114116#114196 > > I think I disagree with this very strongly, and plan* to vote against > any RFC that embeds another language in annotations.** > https://blog.softwaremill.com/the-case-against-annotations-4b2fb170ed67 cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Planning ahead, will 8.5 exist and major version decisions (was: Deprecate functions with overloaded signatures)
On Sat, 13 May 2023 at 00:08, Larry Garfield wrote: > > I am actually tempted to propose that we do deprecations at the very > start of a release, 9.0 and 9.1 only, and then not allow them for the > rest of that major, for that exact reason. That sounds really unwise. People aren't that enthusiastic about volunteering to work on things that would take 5 years to deliver a change. It would make maintaining PHP be a lot harder, and also be a burden on core maintainers. On Mon, 15 May 2023 at 09:55, G. P. B. wrote: > > Why are we assuming that PHP 9.0 is going to come after PHP 8.4? Partly because I experience time linearly? And afaik, no-one has a lot of negative emotional feelings about the number 9. But I guess maybe you meant, "why are people assuming PHP 8.5 won't exist?". On Mon, 15 May 2023 at 19:39, Larry Garfield wrote: > > Tangent: If I were to put together an RFC that set out such a 5 year cycle > expectation with reasonable guidelines around when things could be deprecated, > would anyone actually support it? I think that would cause more drama. IMHO, you seem more attracted to having processes and schedules written down, than core devs appear to.[1] Although we should probably discuss when major releases happen, we should start that conversation off by asking questions. I've only been taking part in internals discussions for two major releases, and it's pretty unclear to me how the decision to stop releasing on the 5.x and 7.x branches was made. I would appreciate any core contributors[2] thoughts on any of the following: * Are there any things being worked on that would deserve or require a major version bump in PHP? * In particular, should we expect PHP 8.5 to be a thing, or should we expect PHP 8.4 to be the last release of the PHP 8.x branch? * Is there, or could there be, a process for planning when the next major release is going to happen? Or would requiring volunteers to plan their volunteering multiple years in advance be too much of a burden? cheers Dan Ack [1] I agree with the people who actually do the maintenance here. Fixed processes don't actually help that much on a project the size of PHP. Most of the time people are sensible and can be reasonable about things, even if their priorities aren't the same as other people, and so to outsiders they don't appear as reasonable. [2] I am sure lots of userland people and other people will have opinions also. I just don't think they will be as insightful or useful in this conversation. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures
On Sat, 13 May 2023 at 00:08, Larry Garfield wrote: > > That means it's impossible to write code that works from 8.2 to 9.0 without > version checks. The overlap period is only 2 releases (8.3 and 8.4). That's > too short of a window. That it is too short, is an opinion. Having one version where both the old version of the function, and the new version work is the minimum (imo) as it allows people to run the same code on both. But anything more than that is a nicety, not a requirement. Also, in my opinion. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Please remove the Sicherheitsüberprüfung Security captcha from php.net
On Sun, 14 May 2023 at 22:59, Hans Henrik Bergan wrote: > > I'm not sure there is an English version at all For me, there is an English version below the German version, Er, and apparently for you also: https://phpimagick.com/deutsche_uber_englisch_2.png > my Accept-Language doesn't mention German, and it > specifically requests English, My guess, content negotiation is a really low priority for a DOS protection service. > it specifically requests English, and I'm not accessing the german > de.php.net, so if an English version existed, there would be no reason > for it to give me a German version, Englisch ist nicht die Standardeinstellung. For a German company, providing services to German speaking countries, putting the German version above the English version seems a reasonable reason. I believe Derick has sent an email message to noc@ and systems@, so hopefully something will be adjusted. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Discussion] nameof
On Sat, 13 May 2023 at 08:27, Robert Landers wrote: > > Hello Internals, > > It is with much trepidation and excitement that I'd like to announce > the `nameof` RFC (https://wiki.php.net/rfc/nameof). Can you provide more details on what the error conditions are? I can see 'non-existent static variable' and 'non-existent variable', are there others? > An exception model was considered, however, the author believes that > it would break the concept of “using nameof wherever a string could > be used” and wouldn't be practical for the engine to handle all of > those cases. Can you put some detail in there I don't understand the problem, or what you mean by it not being practical to 'handle all of those cases' . > each one has its own merits but ultimately will > be left up as a secondary vote: One of the reasons the RFC process has served PHP pretty well is that it forces people to think through the details. I really don't think putting a few options up and hoping that people choose the best one is a good way to design a language; it allows skipping over thinking the details through. And yeahthis is one of the reason doing RFCs is annoying. People are often persnickety over details. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures
On Thu, 11 May 2023 at 10:36, Tim Düsterhus wrote:
>
> I believe this vote format ("three options") is not really compatible
> with the voting rules (https://wiki.php.net/rfc/voting).
>
> For example it's not entirely clear what would happen here:
>
> 5 votes to deprecate in 8.3 / remove 9.0
> 4 votes to deprecate in 9.0 / remove 10.0
> 4 votes to not deprecate.
The RFC author could just say that yes votes for deprecation and
eventual removal will be added together, with the timescale being a
preference vote.
I think the only people who would object to that are people who would
vote yes to "deprecate and remove" but only if it matches their
preferred timescale, and would otherwise vote no. Which probably isn't
a thing.
cheers
Dan
Ack
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures
On Thu, 11 May 2023 at 10:36, Tim Düsterhus wrote: > > Would it be an option to just deprecate everything in PHP 8.3 As I said before, having at least one version where the new versions of the functions are available, and the old versions aren't giving deprecation notices, is the 'cleanest' way of refactoring functions. Deprecation notices only deliver their value when the old versions of the functions are removed, and before then are a cost. > It doesn't really feel right to decide on > a deprecation for 9.0 / removal for 10.0 at the current time, but > deprecation in 8.3 + removal when it's ready seems to be okay. I think I don't understand your concern. If a problem is discovered with a planned removal of something, people on this project are mostly reasonable*, and a small RFC to adjust to the new circumstances would be very likely to pass. cheers Dan Ack * though sometimes they base their decisions on experiences/value different from my own, which makes it not feel like that. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] DB specific PDO subclasses questions.
On Tue, 7 Jun 2022 at 15:25, Philip Hofstetter wrote: > > On 6 Jun 2022 at 21:15:12, Dan Ackroyd wrote: >> >> 2. Other than the SQLite blobOpen functionality, does anyone know of >> any other functionality that is exposed by SQLite or Postgres that >> isn't currently exposed through the magic PDO methods? > > a wrapper around PQescapeIdentifier in libpq could be useful. Okay. Any idea if PQescapeByteaConn should also be added? cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures
>From the RFC:
>
> Code which invokes get_class() without parameters should be modified to
> use __CLASS__ or get_class($this) instead,
I don't think the first option is equivalent:
class C {
function printType() {
echo "__CLASS__ is " . __CLASS__ . "\n";
echo "get_class is " . get_class($this) . "\n";
}
}
class D extends C {
function printTypeInChild() {
echo "__CLASS__ is " . __CLASS__ . "\n";
echo "get_class is " . get_class($this) . "\n";
}
}
(new D)->printType();
(new D)->printTypeInChild();
// Output is:
__CLASS__ is C
get_class is D
__CLASS__ is D
get_class is D
And unless I'm missing something, the second option doesn't appear
usable with static methods, which is also a problem with
get_parent_class()
> while code which invokes
> get_parent_class() without parameters should be modified to use
> get_parent_class($this) instead.
What would the equivalent code get_parent_class() for static methods? e.g.
class A {}
class B extends A {
public static function foo() {
echo get_parent_class() . " \n";
}
}
b::foo();
cheers
Dan
Ack
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures
Kamil Tekiela wrote: > > I think one year of deprecation is not enough... It doesn't make > > sense to me to add a replacement but not deprecate the old variant. Máté Kocsis wrote: > Yes, this upgrade path also makes sense to me, and I'm happy to go with > it if others don't disagree! For the functions that are having new separate methods added, not deprecating them immediately makes upgrading easier. When upgrading from one version of PHP to the next, it is best if you can run the same code on both versions, without any deprecation notices going off. Would leaving the current versions in place and working actually cause any maintenance issues? If not, then we could just move really slowly on deprecating them. We could deprecate them at some point in the 9.x release cycle and remove them in 10.0. The RFC says: > Impact analysis: 1 out of the 2000 most popular PHP packages rely on calling > session_set_save_handler() with 6 or more arguments. I doubt analysing github is going to give a useful measure of the impact of this RFC. Functions like session_set_save_handler are going to be used in custom code written for a company than in shared libraries. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Current RFC process and project decisions
On Mon, 1 May 2023 at 12:21, Jakub Zelenka wrote: > It seems that in the current definition, the RFC is just for blocking > rejected features to get to the next release rather than requiring accepted > features to be in the next releaseIt means it requires some > sort of consensus between core developers or at least no objections from > some core developers. It might be better to think of the RFC process for new features to be a decision on "should this feature be in PHP?" rather than a "must this feature be in PHP?". As far as I can remember, there is a single RFC that wasn't merged in the next planned release: https://wiki.php.net/rfc/null_coalesce_equal_operator The vote was passed on 2016/04/02 so 7.1 was the next release version, but it wasn't merged until 2019/01/22 and so was in PHP 7.4. That was due to a technical problem with the implementation - I don't recall/understand the exact details. But it wasn't (afaik) a controversial decision to not merge it until the patch was good enough. This was possible to happen because we don't require a complete patch that is ready to merge. Ironing out all of the minor details for a new feature is a huge amount of work (that people in userland are usually completely oblivious to) which would increase the burden of passing RFCs. Seeing as one of the big long term problems PHP has, is that many contributors stop contributing after they get burnt out by doing an RFC, I would oppose making RFCs take more work. Once an RFC is passed the conversation changes from whether the RFC is a good idea or not, to being a conversation about how to best implement it, and whether the patch has some show-stopper issues or not. > This is largely undefined as almost always the core > developers would follow the decision in RFC but technically there is > nothing in our process that would require them to do so. Technically correct. Though the situation where all of the core contributors refuse to merge a PR, probably means the PR shouldn't be merged. > The idea is to maybe create a single document in the wiki collecting both > linked RFCs with extended clarifications and maybe mirror it in git so the > future proposal are easier to do. At the risk of being a senior programmer; what problem are you trying to solve? I mean, clearly there have been problems that could do with clarifying: * when are and what types of code cleanups allowed to happen? What notice should be given, to avoid causing work for other developers, who might have large existant branches they've been working on? * are pull-requests that merely add comments allowed? This is something some long-time core contributors have strong feelings about, which I and other people disagree strongly with, but we haven't had a framework to discuss it without shouting. And there are probably other non-userland affecting code maintenance tasks. But as far as as I'm aware, there hasn't been a problem with an RFC passing and the core contributors refusing to accept it. So please can we discuss the exact problem you want to solve, so that we can agree it's the right problem to solve, before suggesting solutions? If nothing else, some problems are unsolvable by lots of documentation and bye-laws. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [Discussion] Callable types via Interfaces
On Thu, 20 Apr 2023 at 18:25, Larry Garfield wrote: > > Hi folks. This is a pre-discussion, in a sense, before a formal RFC. Hi Larry, The "Allow casting closures into single-method interface implementations" one seems a complete non-starter, as that seems really hard to work with. You'd have to do lots of "wiring up" to do any significant amount of programming. "Allow Closures to Declare Interfaces they Implement" That sounds bad as it doesn't allow arbitrary functions to be used as callables. > We feel that the interface-based approach is strong All three of them are using interfaces...? But if you mean the "Structural Typing for Closures" one, then I'd probably agree. But as currently proposed it seems like a hack, that would be predictably regrettable in a couple of years. > and a good way forward for getting typed callables > without a bunch of dependent features needed first. Maybe list what you think the dependent features are, so that there isn't confusion about them, but I suspect that we're going to not agree on how languages should be designed and evolve. Although I really want to see typed callables, and other forms of type aliasing, as they would be huge improvements in being able to write code that is easy to reason about and maintain, I don't want to seem them as soon as possible, having taken short-cuts against good language design. "No is temporary, yes is forever". cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] New core autoloading mechanism with support for function autoloading
On Thu, 13 Apr 2023 at 11:39, Jordi Boggiano wrote:
>
> On 2023-04-12 22:26, Rowan Tommins wrote:
> > I could just about live with that example changing so that the
> > fallback was cached, but I definitely don't think an explicit call
> > like \foo\strlen('x') should become an implicit alias for
> > \strlen('x'), which is apparently the current proposal.
> >
> > I really like the majority of this proposal, but right now would vote
> > against it based on that.
> >
> I agree here, I missed that fact while reviewing the RFC as I just
> understood it as an internal cache that \foo\strlen => \strlen, but
> function_exists('foo\strlen') should still return false IMO until it is
> defined, and once it is defined the cache should be busted.
Thanks for the code example. Code is a great of being clear...
particularly when I've gotten the wrong end of the stick.
Yeah, that would be a BC break.
For now, I'll update the RFC words to say that, but that means we need
to go and do some thinking, to figure out how to proceed.
cheers
Dan
Ack
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] New core autoloading mechanism with support for function autoloading
On Mon, 10 Apr 2023 at 14:01, Ondřej Mirtes wrote: > > I don’t like the proposed function names: I think we're going to leave thinking about changing the names until the end of the discussion. They don't really matter, and it probably would be better to avoid clogging up the technical discussion with people's aesthetic beliefs. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] An invitation to chat and some useful links about PHP internals and extensions development
Hi Internals,
If anyone is looking for help either developing extensions or work on
internals/PHP core then the PHP chat room ('Room 11' aka R11) on
StackOverflow quite often has some internals contributors lurking
around, waiting for interesting conversations to take part in:
https://chat.stackoverflow.com/rooms/11/php
There are guidelines for do's and don'ts here
https://room-11.github.io/ but the main thing I would strongly
recommend is that asking questions is a way more effective of gaining
knowledge than "declaring solutions to a problem", particularly when
not everyone agrees what the problem is.
Unfortunately being able to write in StackOverflow chat does require
20 fake internet points (aka reputation). If anyone is desperate to
join with a specific question and doesn't currently have enough
reputation, feel free to contact me on Twitter (@MrDanack) and
something can be arranged/manipulated.
## Thoughts on English + communication problems
I realise I am lucky to be a native speaker of the language that
happened to be the one most widely used for international
communication, and so I've never had to endure having to ask technical
questions in a language other than my own. Having said that ...
### Most people seem to underestimate their English skills
Non-native English speaker: I am awfully sorry at the terrible state
of my English abilities, as for the English language is not my mother
tongue. I hope you forgive me for every foolish mistake I make.
Native English speaker: lol, it okei.
Most of the time, I am only reminded that someone is not a native
English speaker, when they explicitly say it.
### There is no standard English
There is 'quite' a bit of diversity in how English speakers talk. Even
amongst native English speakers, there may be a small amount of effort
needed by the recipient to understand what is being said.
https://www.youtube.com/watch?v=bzDtmMXJ1B4
https://www.youtube.com/watch?v=WjTIFkWJctY *
https://www.youtube.com/watch?v=G8LeDANQ7UE
In Britain, it's always on the recipient to put the effort into
understanding, or apologise for not understanding with something like
"sorry, I don't quite get what you mean."
Anyone who thinks less of someone else for not being fluent in
English, probably isn't someone you would want to interact with
anyway.
### There are more fundamental problems
There's a couple of patterns I see, that seem to get in the way of
having productive conversations.
Some people write
like this all the time
not writing fully formed thoughts
just typing as they think
putting words in the chat room
without forming
long sentences into comprehensible thoughts
Other people seem fundamentally unable to actually ask a question.
i.e. they will describe a problem they have (sometimes with some code
attached) and they expect someone to be able to read their mind, to
see what precise question they want help with. Even when someone says
"what is your exact question?", they don't seem to understand that a
question needs to be asked, before it can be answered.
There are other patterns, but this email is long enough already.
But if anyone wants advice on how to communicate better, particularly
if you're feeling frustrated about not feeling able to get your point
across, feel free to ask me on twitter or Room11 (I check those more
frequently than email).
## Other resources for internals development.
At https://heap.space/ there is an instance of OpenGrok setup for PHP.
OpenGrok is a search tool for code, and this site allows searching and
navigating through various versions of PHP.
The PHP Internals Book (http://www.phpinternalsbook.com/) is the most
comprehensive resource for learning how PHP works internally, and how
the functionality can be updated. I'd recommend reading all of it, but
here are a few choice articles which are pretty vital to read.
* Learning the PHP lifecycle:
https://www.phpinternalsbook.com/php7/extensions_design/php_lifecycle.html
* Zvals: https://www.phpinternalsbook.com/php7/zvals.html
* Zend Memory Manager:
https://www.phpinternalsbook.com/php7/memory_management/zend_memory_manager.htm
Zend have a guide to 'Writing PHP Extensions' here:
https://www.zend.com/resources/writing-php-extensions which apparently
might be more up-to-date on some parts of PHP's internals.
Thomas Weinert has a comprehensive set of examples
(https://github.com/ThomasWeinert/php-extension-sample) of how to
implement features in PHP internals, where each branch implements a
single feature. The way to use this set of examples is to find the
branch that contains what you want to implement, check it out, and
then look at the commits in that branch to see what was done.
cheers
Dan
Ack
* the gentlemen in the second video were from less than 50 miles away
from me. I am reasonably certain I understand spoken Dutch more than I
understand them. I do not speak Dutch.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
Re: [PHP-DEV] First class callable syntax for instance methods
On Thu, 13 Apr 2023 at 07:30, Robert Landers wrote:
>
> This has been brought up a couple of times, but I can't seem to find
> it.
https://externals.io/message/119392
https://externals.io/message/120011
> I don't think something like this is possible with the current
> implementation of first-class-callables (it would need a major
> refactor).
It's not currently possible, but it wouldn't need a huge refactor...we
could just do what Java does:
https://www.baeldung.com/java-method-references
https://docs.oracle.com/javase/tutorial/java/javaOO/methodreferences.html
// If we copied the Java way of doing it, this:
// $fn = Verification::getId(...);
// $fn would be equivalent to:
$fn = fn (Verification $v) => $v->getId();
And if the method of the class has parameters, those would be after
the first instance parameter:
class Foo {
function bar(int $x) {}
}
$fn = Foo::bar(...);
// Would be equivalent to:
$fn = fn (Foo $f, int $x) => $f->bar($x);
I can't see a technical reason not to do it like this, but some people
seem to be having negative gut reactions to it, and it's hard to
persuade someone about aesthetics.
Notes here: https://phpopendocs.com/rfc_codex/class_method_callable
cheers
Dan
Ack
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] New core autoloading mechanism with support for function autoloading
On Wed, 12 Apr 2023 at 17:32, Claude Pache wrote: > > The proposed modification of `function_exists()` will break existing code: Please can you submit a failing test to https://github.com/Girgias/php-src/tree/zend_autoloader that shows a BC break. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] New core autoloading mechanism with support for function autoloading
On Tue, 11 Apr 2023 at 18:12, Hans Krentel via internals wrote: > > So I'd love to see some commentary on a `function_alias()` > if now function autoloading is considered to come in I wouldn't be opposed to it, but it should be a separate RFC. The implementation could be copied from https://www.php.net/manual/en/function.runkit7-function-copy and probably wouldn't be that complicated, or conflict with this RFC. > It was the latter which brought us `class_alias()` [0] > and I've used it often in code migrations Yes, in particular the changing from Twig_Template_Loader to Twig\Template\Loader migration. I'll add it to my list at https://phpopendocs.com/rfc_codex It would seem a good "my first RFC" for someone. Though, function migration could also be solved in a far more powerful way. Check my forthcoming reply to Rowan... cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] New core autoloading mechanism with support for function autoloading
On Wed, 12 Apr 2023 at 09:24, Nicolas Grekas wrote: > > I would like to see a similar benchmark with function autoloading enabled. > https://github.com/phpbenchmarks/ Can you point me to where one can tell the benchmark framework to use a custom version of PHP? > One of the big differences you'll see between PHP 4 and PHP 5 codebases is > the number of source files - when people had to manually list each file to > include, they tended to bundle things into larger categories; Yes. Or to put it more generally, the ergonomics of using a language (aka the developer experience) affects how people think and write code. I'm just going to quote someone from Reddit and my reply, because it captures the essence of the situation perfectly: TheBroccoliBobboli wrote in /r/php >> I'm struggling to see the advantages of this vs working with static >> class functions, e.g. Helper::function(). >> >> That's mostly because I can't even remember when I last declared a >> function outside of a class in any serious project though. > Danack wrote: > That the ergonomics of using functions in PHP is currently so bad, that you > don't use them, is proof enough of why the ergonomics of using them needs > to be improved, and autoloading is the most obvious improvement. Nicolas Grekas wrote: > Then comes my second main question: what does this solve? Or, to appeal to a higher authority: "There is this one thing that I noticed recently and that concerns me: PHP devs don’t use functions." - Nikita Popov https://www.npopov.com/2012/08/10/Are-PHP-developers-functophobic.html Nicolas Grekas wrote: > It doesn't enable anything that a script generating a list of include statements couldn't Exactly the same argument could made against class autoloading. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] New core autoloading mechanism with support for function autoloading
On Tue, 11 Apr 2023 at 08:14, Michał Marcin Brzuchalski wrote: > > Can we improve the RFC with a short description of issues on SPL autoload > this RFC tries to address? Sure, if you want to propose some clearer words than these: "The spl_autoload_register() does not become an alias for autoload_register_class() to preserve BC by continuing to return true, allowing it to register the default SPL autoloader, and accepting the ignored second parameter, but they are both forwarded to an identical internal implementation." The RFC could always be improved. But the main reason to separate the autoload functions from the SPL, is that imo autoloading probably should never have been part of SPL. At the time, new functionality was dumped into SPL as a convenient place to put stuff. At some point (probably after distributing extensions becomes a lot easier) moving the SPL away from PHP core might be a sensible thing to do, as the SPL has some 'not great' design choices that are pretty impossible to solve: https://phpopendocs.com/rfc_codex/spl_summary Or at least impossible to solve while the release cycle of the SPL is tied to that of PHP itself. But autoloading would need to stay as part of PHP core itself. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] New core autoloading mechanism with support for function autoloading
On Tue, 11 Apr 2023 at 09:48, Rowan Tommins wrote:
>
> Similarly, I think it should be possible to "unpin" a function
> lookup with a later definition,
Can you say what the technical justification for that is?
There's reasons why (imo) it's probably wrong, but I don't currently
understand what you would want it for, so want to make sure I don't
miss something in my response.
> This isn't actually true: classes, interfaces, traits, and enums all share
> a symbol table, and thus an autoloader. I don't know of a good name for
> this symbol table, though.
As per the RFC it would probably just be 'type'. When PHP is compiling
some code:
function foo(Bar $bar): Quux { ... }
Before 'Bar' and 'Quux' are loaded, the only thing that is safe to
assume about them is that they are a type, whether that be a class
either with methods or without (also called an interface), or an enum,
or eventually a type alias like `type number = float|int;`.
> Regarding the API, would it be possible to take advantage of nearly
> all autoloaders only being interested in particular namespace prefixes?
Lots of things are possible, but I'd strongly prefer to have that be a
separate discussion, which it's listed as a future scope:
https://wiki.php.net/rfc/core-autoloading#higher_performance_through_maps
If nothing else, it's going to take people time to figure out how they
are going to organise code that is 'just' a bunch of functions.
cheers
Dan
Ack
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [IDEA] allow extending enum
Hi Rokas, On Thu, 30 Mar 2023 at 08:36, Rokas Šleinius wrote: > > On Wed, 29 Mar 2023 at 18:40, Larry Garfield wrote: > > > > 1) Please don't top-post. > > Am I doing it right now? I've never been on a mailing list. You're replying in the preferred manner, yes. Quoting only the needed amount and putting replies underneath. Though deleting all non-relevant text is also good. Have two possibly useful guidelines: * Mailing list etiquette guidelines - https://phpopendocs.com/internals/mailing_list * Email etiquette for people new to newsgroups / PHP internals - https://phpopendocs.com/internals/mailing_list_for_younguns which might get copied across to php.net at some point... > In fact, I was too young and missed out on BBS as well, and now using > this laughably archaic collaboration method, receiving mostly > stone-harsh replies generously sprinkled with genius insights, having > to quite literally hack a registration form as one of the several > required steps for contribution... Wow this is a really remarkable > experience for me :D Well, it builds character. And as soon as someone suggests something that is obviously better, and not just replacing one set of problems with another, the discussions might move. > I am really impressed how elegant and actually genius the enum > implementation is. So well rounded, minimal, yet creates so much > value! And it only took the PHP project about 20 years of discussion to get an agreeable implementation... cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] First-class callable partial application
On Tue, 14 Mar 2023 at 16:58, Larry Garfield wrote:
>
> New engine approach first, then syntax based on what that approach allows.
Would it be desirable to split those two things into two separate
RFCs, by having the first RFC not have native syntax support, but
instead another static method on Closure? e.g. something like:
Closure::partial($callable, array $position_params, array
$named_params): Closure {}
and would follow the pattern of Closure::fromCallable() being
implemented in 7.1, and the built-in syntax took until 8.1.
That would also allow creating partially applied functions in a data-driven way.
cheers
Dan
Ack
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Discussion] Typed class constants
Hi Mark, On Sat, 4 Feb 2023 at 00:22, Mark Niebergall wrote: > > This is also a bigger policy question for other seemingly-abandoned > RFCs. If it is agreed that a new RFC should be created in this scenario, I've added some notes on the page https://wiki.php.net/rfc/howto I had some words already prepared from something I will post separately, but may as well post here also: Mailing list etiquette - https://github.com/Danack/RfcCodex/blob/master/etiquette/mailing_list.md Mailing list etiquette for young'uns - https://github.com/Danack/RfcCodex/blob/master/etiquette/mailing_list_for_younguns.md RFC attitudes - https://github.com/Danack/RfcCodex/blob/master/etiquette/rfc_attitudes.md RFC etiquette - https://github.com/Danack/RfcCodex/blob/master/etiquette/rfc_etiquette.md Most of the stuff in there is just etiquette rather than rules, so probably isn't appropriate for the wiki. > I did leave Benas as an author to give him credit for the work he did. Although well intentioned, that's probably quite a no-no. Putting someone's name on something they don't necessarily agree with is likely to cause drama. I've added a note on that also. > With the reverting, valuable community input was dismissed. An effort should > be made to address applicable previous community input instead of just > reverting it out. Probably not. It's up to other people to persuade RFC authors why something should be included, rather than RFC authors having to take time and energy to justify why they are reverting unapproved edits to their RFC. But yep, if you want to do it as part of a separate RFC, go for it. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Pass Scope to Magic Accessors
On Mon, 23 Jan 2023 at 16:27, Nicolas Grekas wrote: > > Legit concerns. I'm going to prepare a more extensive use case so the > motivations of RFC become more obvious. > > I'll get back on this thread when ready. Stay tuned :) Please can you look at implementing it as a function, that returns a more usable set of data than debug_backtrace does. This does sound like useful functionality in other cases than __get. If the amount of data returned by including all the backtrace is a concern, that sounds to me like including an max number of frames would solve that? cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Introduce the abiltiy to use the first-call-callable syntax on non-static methods, statically
On Mon, 23 Jan 2023 at 23:03, Larry Garfield wrote: > > So you're saying that would generate a callable equivalent to: > > $fnMethod = fn (Zok $zok, string $zebranky): Frungy => $zok->Pik($zebranky); Yes. > (We're also now rather far afield from the OP's request, I think.) Well, yeah. Deliberately so. Starting a discussion with a solution prevents people discussing and agreeing on what the actual problems to be solved are, and fixates on a single, in this case 'not great', solution. As I said, I think people should say clearly what the problem they are trying to solve first, before suggesting solutions. > I'd probably push for something more compact as a syntax Quite. Indeed. Yes. Danack wrote: > > Well, other than to use a different syntax. > > https://news-web.php.net/php.internals/114542 $(Zoq, Pik); cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Introduce the abiltiy to use the first-call-callable syntax on non-static methods, statically
On Mon, 23 Jan 2023 at 20:51, Larry Garfield wrote: > > On Mon, Jan 23, 2023, at 12:32 PM, Dan Ackroyd wrote: > > > > > $fnConstructor = Closure::fromClassConstructor(Zoq::class); > > // signature of $fnConstructor is the same as `function(Fot $fot): Zoq` > > > > Or for individual methods: > > > > $fnMethod = Closure::fromClassMethod(Zoq::class, 'Pik'); > > // signature of $fnMethod is the same as `function(Zoq $zoq, string > > $zebranky): Frungy` > > I don't think that actually helps. If you have the object already, Neither of new functions I was suggesting have the object already. Only the type. > If you do not have the object already, then we run back into the issue > I pointed out before where we need to differentiate a bindable from > needs-binding callable, That's not what I suggesting. Danack wrote: > > $fnConstructor = Closure::fromClassConstructor(Zoq::class); > signature of $fnConstructor is the same as `function(Fot $fot): Zoq` That doesn't need a binding at all. Danack wrote: > > $fnMethod = Closure::fromClassMethod(Zoq::class, 'Pik'); > signature of $fnMethod is the same as `function(Zoq $zoq, string > $zebranky): Frungy` First parameter is the object to be operated on. You wouldn't need to do any binding. *magic* would happen inside the function to take care of that. > I think that's a prerequisite for adding any dedicated syntax > for "make a closure that doesn't work until it gets bound". To be clear, I don't support anything like that. As I wrote: Danack wrote: > > That sounds like a complete non-starter. Adding something to the > language that produces a closure that can't be called would be an > instant new entry for PHPSadness. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Introduce the abiltiy to use the first-call-callable syntax on non-static methods, statically
On Sun, 22 Jan 2023 at 17:45, Ollie Read wrote:
>
> Hello all,
Hi Ollie,
> I've created a feature request issue on GitHub (here:
> https://github.com/php/php-src/issues/10414), but I have been advised that
> it's best to post here.
> ...
> I think we could delay the error until the closure was called.
That sounds like a complete non-starter. Adding something to the
language that produces a closure that can't be called would be an
instant new entry for PHPSadness.
> Whereas it would be much nicer to have the following:
>
> ```
> $collection->filter(Str::empty(...));
> ```
>
> In this situation, the collection library would be responsible for binding the
> closure to the value it is iterating.
How would the collection library know it was safe to bind the closure
to each value it was iterating over? It sounds really type unsafe.
> What I would like to introduce/suggest, is the ability to create a closure
> from a method using the first-class-callable syntax...
>
> The more I think about it, the more I think this may require a new ...
I think people should say clearly what the problem they are trying to
solve first, before suggesting solutions.
I think there's at least a couple of problems that can be thought about:
i. Although the first-class-callable syntax allowed avoiding string
based programming for most callables, it doesn't support referring to
some things that you would want to call, including both instance
methods, and constructors*.
ii. Representing an instance method requires at least two pieces of
info; which class it belongs to (which can be used to find the
constructor) and the parameters of the method itself. That doesn't
naturally fit into a closure.
iii. The appropriate syntax for referencing a class instance method
without it being string based isn't obvious. Or at least it isn't
obvious to me.
iv. Writing code that for callback methods is longer than it could be,
e.g. as Larry Garfield wrote:
> So what you're really looking for is a shorter way to write this:
>
> foo(fn(Str $s) => $s->beep());
At the risk of suggesting an abomination, given a class of:
class Zoq
{
public function __construct(private Fot $fot) {}
public function Pik(string $zebranky): Frungy {...}
}
If it was possible to generate callable for the constructor with:
$fnConstructor = Closure::fromClassConstructor(Zoq::class);
// signature of $fnConstructor is the same as `function(Fot $fot): Zoq`
Or for individual methods:
$fnMethod = Closure::fromClassMethod(Zoq::class, 'Pik');
// signature of $fnMethod is the same as `function(Zoq $zoq, string
$zebranky): Frungy`
That sort of looks like a solution to most of the problems I think exist.
For your particular problem, I believe that would allow:
$fnMethod = Closure::fromClassMethod(Str::class, 'empty');
$collection->filter($fnMethod);
Which isn't shorter, but at least allows passing the callables around
with the type inspectable. Though it might be nicer if PHP had the
ability to definte function signatures types.
That sort of solution obviously doesn't address the problem of having
to refer to the class method as a string, but as I said, I don't have
a suggestion for that. Well, other than to use a different syntax.**
cheers
Dan
Ack
* constructors having their own terrible history.
** https://news-web.php.net/php.internals/114542
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Loading SQLite extensions on PDO
Hi Juris, On Fri, 20 Jan 2023 at 14:26, Juris Evertovskis wrote: > > Hey, internals! > > As many before me, I have come accross a need to load a SQLite extension. > > - The community does not want a new driver-specific `loadExtension` method > on the PDO class (there are some historical driver-specific methods). I'm planning on submitting https://wiki.php.net/rfc/pdo_driver_specific_subclasses in a few weeks*, which will allow per-driver specific methods in a 'proper' way. cheers Dan Ack Well in time for inclusion in PHP 8.3 at least. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly
On Fri, 25 Nov 2022 at 00:07, Larry Garfield wrote: > > On Sun, Nov 20, 2022, at 7:20 AM, Dan Ackroyd wrote: > > Hi Larry, > > > > Regarding the syntax, up until now PHP has only supported the letters > > a-z and underscore in keywords. > > > > I realise this is an aesthetic thing, but "private(set)" looks like a > > function to me, and not a keyword. I saw the previous poll, and it > > didn't include options for either protected_set/private_set or > > protectedset/privateset. > > > > Was there a technical reason for excluding them as an option? > > Not in particular. We originally proposed `private(set)` because that's what > Swift uses. In the discussion people proposed several alternatives that I > put into the poll, but `private_set` wasn't one of them. Although several > people said they were opposed to parens in the keyword, Have you considered updating the RFC to use private_set, and not introduce new characters for keywords? As it wasn't in the poll, then sticking to the poll result with at least some people saying they are opposed to it seems not necessarily the correct choice. The ()'s look particularly funky to me with property promotion. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] More Appropriate Date/Time Exceptions
On Sat, 10 Dec 2022 at 10:06, Robert Landers wrote:
>
> However, I generally feel that the program will always have access to
> the raw data, after all, it is unserializing it.
Not always in a useful way.
function getMeeting(DB $db, int $meeting_id): Meeting
{
$meeting_data = $db->getUserSettings($meeting_id);
return unserialize($meeting_data);
}
If the $meeting_data included invalid DateTime info, the info wouldn't
be in the stacktrace. Investigating that issue would require someone
manually extracting some data from the production DB, which
programmers shouldn't have direct access to.
Tim Düsterhus wrote:
>
> instead an actual human has to look at the error
> message and possibly stack trace within the error log / within Sentry /
> whatever floats your boat.
When the info isn't completely contained in the exception message
itself, what tickles my fancy is having small functions that format
specific exception types into an easy to understand to comprehend
piece of info, so that no-one has to spend time trying to read a
stack-trace.
> I'm against ext-specific or library-specific exception classes
> for unserialization failures,
Good point.
I'll raise it again when there is another discussion about an
UnserializeException.
Although it would probably be safe to expose invalid data that was
meant to be turned into a DateTime object, it's not obvious that it
would be safe to increase the exposure of arbitrary data, as it might
include PII data.
cheers
Dan
Ack
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [Vote] More Appropriate Date/Time Exceptions
On Sun, 18 Dec 2022 at 16:48, Theodore Brown wrote: > > why it's okay to make a BC break for the OO API, > but not for the procedural API. Because they are different APIs. People who use OO apis are used to handling exceptions and would expect failures in OO code to throw exceptions. That the DateTime OO api isn't currently do so is not conformant to their expectations. People who use the procedural apis of DateTime, or procedural versions of the Intl functionality (e.g. NumberFormatter vs numfmt_format_currency) claim to prefer checking date_get_last_errors(), numfmt_get_error_code() etc., rather than have to worry about exceptions. Changing the procedural functions to use exceptions would be a bigger and more controversial change than the one proposed in this RFC. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] More Appropriate Date/Time Exceptions
On Thu, 8 Dec 2022 at 15:05, Tim Düsterhus wrote: > > If your data fails to > unserialize, the only safe option is to throw it away. Even given that, you probably want to investigate how it got corrupted so that you can stop it from happening again. And doing that would rely on being able to see the data that you attempted to unserialize. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] More Appropriate Date/Time Exceptions
On Tue, 29 Nov 2022 at 17:41, Derick Rethans wrote: > > I have just published a new "More Appropriate Date/Time Exceptions" RFC > > > Comments? > None of the 'Invalid serialization' errors tell the programmer who reads them what is wrong with the data. Unless the code was written in such a way that the data was in (and was logged) in the callstack, that would be a bit frustrating as someone might need to do quite a bit of work to find the data that was triggering the problem. Changing those to be specific error type, that included a method of 'getBadData' could make it easier to fix those issues. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly
Hi Larry, Regarding the syntax, up until now PHP has only supported the letters a-z and underscore in keywords. I realise this is an aesthetic thing, but "private(set)" looks like a function to me, and not a keyword. I saw the previous poll, and it didn't include options for either protected_set/private_set or protectedset/privateset. Was there a technical reason for excluding them as an option? On Sun, 13 Nov 2022 at 20:09, Larry Garfield wrote: > > That creates an odd situation where readonly and asymmetric visibility > may only be combined "sometimes."... > > 2. Disallow readonly and asymmetric visibility being combined, because > readonly already has a hard-coded implied asymmetric visibility. This is getting quite complicated. I think unless someone makes a strong case for allowing the combination of the two, disallowing them being combined is probably the best choice. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Adding the OpenSSF Scorecards GitHub Action
Hi Pedro, On Mon, 24 Oct 2022 at 19:06, Pedro Nacht via internals wrote: > > Hey Jordan, You seem to have responded to Jordan's tech questions, but I was really hoping for an answer to my more fundamental questions: Danack wrote: > What is the morality of open source? > What is the morality of encouraging people to contribute to open source? Thoughperhaps we should start you off with an easier question. What is the morality of OpenSSF asking projects to add these scorecards to their projects? I'll even give you a hint; try describing the motivations of the OpenSSF (and it's backers) and how they differ from contributors to open source projects. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Adding the OpenSSF Scorecards GitHub Action
Hello Pedro. On Thu, 20 Oct 2022 at 23:26, Pedro Nacht via internals wrote: > > I'm happy to answer any questions anyone might have What is the morality of open source? What is the morality of encouraging people to contribute to open source? When people see open source projects being abused by multi-billion dollar companies, should they stay quiet or should they ask really annoying questions on the mailing list? > First time contribution to the mailing-list, apologies > for any missteps! Apologies in advance for being difficult, but a lot of people who have contributed to Open Source for years have quite strong feeling about events that have occurred, and manipulation by large companies. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Improve unserialize() error handling
On Wed, 19 Oct 2022 at 19:11, Tim Düsterhus wrote: > > While the behavior would in fact change, it would not introduce a > "security issue" if this what you were hinting at. No, just that it would break in production, and then have to be fixed after a live site was already affecting end-users. > This would just result in an uncaught Exception which should > be very visible in your error tracking service. My impression is that most web-servers running PHP don't have those. For people who run most sites, the first they would know about it is when end-users started complaining. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Improve unserialize() error handling
Hi Tim,
On Fri, 14 Oct 2022 at 15:44, Tim Düsterhus wrote:
>
> Hi
>
> as announced on Wednesday [1] I've now opened the vote for:
>
> "Improve unserialize() error handling" [2]
I'm going to have to vote no for changing to throwing an exception.
The BC break is too big imo, and too hard for people to be aware of.
IMO There needs to be a clear path of deprecating the current
behaviour that people are alerted to (rather than having to read
upgrade notes), so that they know they need to change their code from:
function getUserPreferences($data) {
$user_preferences = @unserialize($data);
if ($user_preferences === false) {
$user_preferences = get_default_preferences();
}
return $user_preferences;
}
to something like:
function getUserPreferences($data) {
try {
return unserialize($data);
}
catch (UnserializationFailedException $ufe) {
return get_default_preferences();
}
}
but I'm not having great ideas of how that could be done 'nicely'.
Similar for the exception hierarchy change (example is below).
Changing the type of exception thrown would break valid (if not super
great) code in a way that would be hard to detect, and I'm not sure we
have a good way of performing this type of change.
IMO these isn't just a BC break that needs to wait for a major version
release; it's something that needs to have a clear upgrade path no
matter which version they are proposed for.
btw I think there are underlying interlinked problems with PHP that
causes proposed changes like these to be more difficult than anyone
would want:
1. The PHP core library is 'ungood' in quite a few aspects, and many
people would like to improve it, but some of those changes are hard to
do in a BC way.
2. Because of the way PHP works, it's not possible for one
library/module to use different versions of the same function. This is
different from JavaScript where with their (ridiculously convoluted*)
tools, each module is able to specify exactly which versions of which
libraries it wants to use.
3. Although PECL was good for the time it was created in (where it was
uncommon for individuals to have places to share files online) it
really isn't a tool fit for purpose any more. It's not really fit for
purpose any more, as even when there are (allegedly) great libraries
like ds (https://www.php.net/manual/en/book.ds.php) relatively few
people using PHP use them.
I think trying to improve the situation, so that changes to individual
functions avoid even requiring a discussion in internals in the first
place, is a worthy goal. But it's one that would require many multiple
years of effort, so is far too difficult to be done by individual
people volunteering their time.
Addressing problems that are far too large for individual contributors
to fix, is possibly a discussion to be taken up by the PHP Foundation.
If anyone who works for a for-profit company has read this far and
their company isn't already sponsoring something like 1% of their
engineers salaries to the foundation, then I encourage you to do so at
https://opencollective.com/phpfoundation .
For the "Increase the severity of emitted E_NOTICE to E_WARNING"
part... I offer no opinion on the change. I personally think any
project that doesn't convert any unsilenced warning to an exception is
just asking for trouble.
cheers
Dan
Ack
* I wouldn't want to see a 'standard' library for PHP split across
80,000 repositories, but I think that the one (1) standard library
that PHP has is too few. Which possibly gives somes bounds to the
desirable number of libraries for a programming language.
// Example for __unserialize exception
class UserNotFoundException extends \Exception {}
function check_user_exists($user_id)
{
// check user account hasn't been deleted, otherwise throw:
throw new UserNotFoundException("exceptions for flow control are great.\n");
}
class User
{
private $id = 5;
function __unserialize(array $data) {
check_user_exists($data["\x00User\x00id"]);
}
}
$user = new User();
$data = serialize($user);
echo "$data \n";
try {
$result = unserialize($data);
}
catch (UserNotFoundException $unfe) {
// This exception would no longer be caught if the exception type
was changed.
echo "redirect user to login page\n";
exit(0);
}
echo "User is valid.\n";
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC [Discussion]: Randomizer Additions
Hello Joshua, > Shall an option be added to getFloat() that changes the logic to select from [$min, $max] (i.e. allowing the maximum to be returned)? And how should that look like? Boolean parameter? Enum? An enum would probably be nice, and possibly be for all four cases of min_(inclusive|exclusive)_max_(inclusive|exclusive) unless there is a technical reason to not include all of them. > Generating a random string containing specific characters...thus requires > multiple lines of code for what effectively is a very simple operation. Yeah, though those lines of code add distinction and emphasis for is meant by character. In particular, users might be surprised when they give this string "abc"* and get a non-ascii result. You're going to need to be really precise on the naming and I'm not at all sure there is a single version that would be useful enough to belong in core. > whereas a 64 Bit engine could generate randomness for 8 characters at once. I'm really not sure that many programs are going to be speed limited by random number generation. For those that are, writing their own generator to consume all 64 bits of randomness for each call sounds reasonably sensible, unless a useful general api can be thought of. For the float side of the RFC, as there are technical limitations on which platforms it would be usable on, there needs to be a way of determining whether the nextFloat and getFloat methods are going to work. The way this is done on Imagick is to put appropriate defines in the stub file and in the C code implementations so that the methods aren't available on the class for the platforms where it isn't going to function correctly. I made a PR for that to Tim's repo, though I don't know of an environment where it can be tested. cheers Dan Ack * For those who get a mangled version, the "characters" there are 'a' 'b' 'c' 'smily-face' 'man + zerowidth joiner + woman + zerowidth joiner + child'. The last is a character that takes a mere 18 bytes to represent. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Casting array to any class
On Sat, 15 Oct 2022 at 13:14, Gianni Gentile
wrote:
>
> What are your thoughts on introduce the `(AnyType)` cast to instantiate
> objects from associative array (or object properties also)?
It seems a pretty bad idea.
In particular, it makes for hard to maintain code as it doesn't give a
place for error checking to occur.
Though I do actually use that pattern in code. Below is a trait that
accomplishes it that should only be used in prototype code. Having it
as a trait means at least I can debug through the initialization and
see if it's missing properties from the array,
But in general, you'd really need to make a strong argument for why it
should be in core, not just why anyone would be against it.
cheers
Dan
Ack
trait FromArray
{
/**
* @param array $data
* @return static
* @throws \ReflectionException
*/
public static function fromArray(array $data): self
{
$reflection = new \ReflectionClass(__CLASS__);
$instance = $reflection->newInstanceWithoutConstructor();
foreach ($instance as $key => &$property) {
$property = $data[$key];
}
return $instance;
}
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC: StreamWrapper Support for glob()
Hi Tim,
On Wed, 14 Sept 2022 at 17:59, Timmy Almroth wrote:
>
> Hello everyone. I would like to announce that the RFC for "StreamWrapper
> Support for glob()" is now ready for Discussion.
The RFC has:
> Final patch will be produced ... if this RFC is approved.
I think that although the RFC discussion can go ahead without a patch,
it would be better to have a patch before it went to vote, as there
seem to be quite a few hidden details that might not be able to be
made to work.
The RFC has:
> Consistently implement StreamWrapper support for glob(). Example:
> glob('vfs://*.ext')
but as noted in the PR (https://github.com/php/php-src/issues/9224),
where cmb69 wrote:
>
> In some cases it just makes no sense (e.g. compress.zlib:// and data://), in
> some
> cases it is impossible (e.g. http://), and in some cases it still might be
> impractical (e.g. ftp://).
The exact details of edge cases probably need to be at least listed as
people (well at least myself) would view a lack of those details as a
reason to vote 'no', even if they thought the general idea was good.
The RFC probably also needs to make an argument of why something that
sounds like it would be a leaky abstraction should be in core (and so
generating more support requests) rather than people using the already
existing userland package
(https://packagist.org/packages/webmozart/glob) which currently has
over 10million installs.
cheers
Dan
Ack
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC [Discussion]: Improve unserialize() error handling
Hi Nicolas, On Thu, 8 Sept 2022 at 18:06, Nicolas Grekas wrote: > > There needs to be serious justification for it. I think this is covered by the RFC. The current behaviour where people have to setup a custom error handler, and then restore the previous error handler, is pretty 'ungood'. The proposed replacement behaviour, where people can actually find out the problem that happened is better. > About 2., unserialize() accepts a second argument to give it options. Did > you consider adding a 'throw_on_error' option to opt-in into the behavior > you're looking for? A new option might be a good idea, but unserialize should have sensible defaults, and the current behaviour is really not that sensible. So, imo, an opt-out would be a better choice. It would allow anyone who cares enough to keep backwards compatibility when they upgrade to the next version of PHP by adding that to the options array, but everyone who is unaware of the option gets the more sensible behaviour by default. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC [Discussion]: Improve unserialize() error handling
Hi Paul, On Sat, 10 Sept 2022 at 12:04, Paul Dragoonis wrote: > > Welcome, Tim :-) > > Do give it more thought regarding the callbacks what Nikolas > said, sleep on it. Although welcoming people is nice, you might want to check that they haven't already had two RFCs passed, and become the maintainer of ext/random. Otherwise "welcoming them" could give the appearance of being quite condescending. Actually in general, people should go out of their way to avoid appearing to speak for an Open Source project, when they aren't contributing regularly. It could be annoying to people who are regularly contributing week-in, week-out. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Vote] Auto-capture closures
On Fri, 1 Jul 2022 at 15:05, Larry Garfield wrote:
>
> The vote for auto-capture closures is now open. It will run until 15 July.
Voting no as:
i) changes in the implementation need more than 1.5 hours discussion
between that change and the voting opening.
ii) The inconsistency of capturing rules between this RFC and arrow
functions are "not obviously" the correct choice. And definitely need
more than 90 minutes of thinking about.
iii) Some of the phrases in the RFC are still just not true.
"Capture is by-value, no unintended side-effects"
"A by-value capture means that it is not possible to modify any
variables from the outer scope"
"Because variables are bound by-value, the confusing behaviors often
associated with closures do not exist."
They are true for scalar values, but not for objects.
RFCs need to be written clearly so that people don't get the wrong
impression if the don't read every single word.
btw for my concerns about object capturing and RAII, the manual could
probably say something like:
> If you want to ensure an object is captured you can either assign it to
> itself:
>
> $foo = $foo;
>
> Or create an empty function:
>
> function ensure_variables_stays_alive(mixed $variable)
> {
>/* function is intentionally blank */
> }
>
> and call that function with the variable you want to stay alive inside the
> closure.
But again, this is "not obviously" the correct choice.
Dan
Ack
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Exception type hint
Antoine wrote: > It could be beneficial for the whole ecosystem to have as well exceptions > type hint. Here are my short notes on the topic. https://github.com/Danack/RfcCodex/blob/master/throws_declaration.md tl:dr someone probably needs to come up with a strong reason for why it would be a good thing. On Wed, 29 Jun 2022 at 17:39, Larry Garfield wrote: > > We are definitely not ready for that kind of fundamental rethink of how > error handling works in PHP. I dunno. The current model is causing quite a few disagreements and pain, and you made a good case for how it could be better. It'd be a huge piece of work, but a better way of handling errors would be a significant improvement for PHP. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Short Closures 2, aka auto-capture take 3
Hi Rowan,
Rowan wrote:
> For that to work, it would require the variable to be captured by
> reference, not value.
> ...
> The only way for it to work would be using capture by reference (not
> supported by the proposed short syntax):
I wrote about this before. Some of the words in the RFC are, in my
opinion, quite inaccurate:
Danack wrote in https://news-web.php.net/php.internals/117938 :
> Those statements are true for scalar values. They are not true for objects:
With automatic capturing of variables, for the code example I gave the
user would want the variable to be captured, and to them it looks like
it should be, but because of an optimization it is not.
When the code doesn't work as they expect it to, the programmer is
likely to add a var_dump to try to see what is happening. Which makes
it look like their code 'should' work, as their resource object is
still alive.
> In fact, the "optimisation" is in my opinion a critical part of the
> semantics, to avoid the opposite problem:
As I said, I think that problem is a lot easier to explain "either use
long closures or change your variable name if you don't want it
captured." than trying to explain "yes, the variable is referenced
inside the closure, but it's not captured because you aren't reading
from it".
cheers
Dan
Ack
For this code, comment the var_dump in/out to affect the lifetime of the object.
class ResourceType
{
public function __destruct() {
echo "Resource is released.\n";
}
}
function get_callback()
{
$some_resource = new ResourceType();
$fn = fn() {
// // why is my lock released?
var_dump($some_resource);
// "Free that resource"
$some_resource = null;
};
return $fn;
}
$fn = get_callback();
echo "Before callback\n";
$fn();
echo "After callback\n";
// Without var_dump
Resource is released.
Before callback
After callback
// With var_dump
Before callback
object(ResourceType)#1 (0) {
}
After callback
Resource is released.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Short Closures 2, aka auto-capture take 3
On Wed, 29 Jun 2022 at 18:30, Larry Garfield wrote:
>
> The conversation has died down, so we'll be opening the vote for this
> tomorrow.
I think I've just thought of a problem with the optimization bit of
'not capturing variables if they are written to before being used
inside the closure'.
Imagine some code that looks like this:
// Acquire some resource e.g. an exclusive lock.
$some_resource = acquire_some_resource();
$fn = fn () {
// Free that resource
$some_resource = null;
}
// do some stuff that assumes the exclusive
// lock is still active.
// call the callback that we 'know' frees the resource
$fn();
That's a not unreasonable piece of code to write even if it's of a
style many people avoid. I believe in C++ it's called "Resource
acquisition is initialization", though they're trying to change the
name to "Scope-Bound Resource Management" as that is a better
description of what it is.
With the optimization in place, that code would not behave
consistently with how the rest of PHP works, where the lifetime of an
object is reasonably well defined with "The destructor method will be
called as soon as there are no other references to a particular
object,".
>From the RFC:
> This approach would result in a waste of memory or CPU usage.
For the record, all of my previous concerns about scoping rules have
been about making code hard to reason about, and behave sanely. Memory
itself is cheap.
Although not having that optimization might mean that some variables
last longer than they should, that is at least explainable*. Having
variables not last as long as they should (because of an optimization)
is harder to explain, and harder to explain how to work around.
cheers
Dan
Ack
* either use long closures or change your variable name if you don't
want it captured.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Under Discussion] Auto-implement Stringable for string backed enums
Hi Nicolas,
On Fri, 24 Jun 2022 at 17:38, Nicolas Grekas
wrote:
>
> I'm now considering withdrawing the RFC because I don't see a way forward
> that could be consensual enough.
Just in general, I think changes to the type system are always going
to take longer than a few weeks to discuss. There are always going to
be subtle implications that need to be thought through thorougly.
Also, the argument for a change to the type system like this should be
based on why it's the right thing to do for new code that is being
written. Although obviously everyone who has a large code base wants
to be able to upgrade to the latest and greatest PHP to get the new
features at the lowest cost in changing code, imo it's more important
long term to get the language right, rather than putting too much
emphasis on lowering the cost of upgrading.
>> Derick wrote:
>> My concern is that auto implementing __toString, will lead to decreasing
>> type safety of enums in weak typing mode, since they get auto-casted to
>> string when passed to a function accepting strings. This effectively adds
>> more type juggling cases.
>
> I don't share this concern: if an API accepts a string and the engine can
> provide a string,
function/method calls are not the only place were type comparisons are done.
My understanding is that if this RFC is passed, then the situation would be:
Foo::Bar == 'Bar'; // true
Baz::Bar == 'Bar'; // true
Baz::Bar == Foo::Bar; // false
Which is not obviously the correct thing.
There is also the issue that callbacks called internally by the engine
are always in weak/coercive mode. That means that changes to
weak/coercive can leak through to code that wants to always be in
strict mode.
> It would be great if we could find ways to make it easier for general-purpose
> libraries to support enums without cluttering libraries with if/else blocks
> and without changing existing interfaces in a backwards-incompatible way.
There's two parts going on here. First, yes, enums could probably be
easier to work with, and we should probably be looking how to do that.
Second is an argument about how easy it should be to retrofit new
features to existing code. Although I can see why people would want
that, it's a lot harder to justify it.
> As experienced on the Symfony repository, this problem is especially visible
> at the boundary of libraries: when some component accepts a string as input,
> ppl want them to also accept backed-enums. This usually means that they
> propose widening the accepted types of some method to make them work
> seamslessly with enums.
Doing that appears to be a violation of the "open for extension,
closed for modification" principle.
If you want to change the type signature, introducing a new function
is almost certainly the 'right' thing to do, even if that means more
work for people with large existing code-bases. e.g.
Change:
class Foo {
function bar(string $quux) {}
}
To this:
class Foo {
function bar(string $quux) {}
function barEx(string|SomeEnum $quux) {}
}
And eventually deprecate the original bar method.
> but we also have a case in Symfony where defining service
> definitions in yaml doesn't work with enums because there
> is no way to express the "->value" part.
I very strongly think the limitations of what yaml config file choices
were made in a downstream project should not influence the design of a
the type system of an upstream project. I'm pretty sure that a
successful RFC isn't going to need to mention that problem.
> If other ppl share my concerns and have a proposal, please let us know.
It might be hard to have a one size fits all rule, hard-coded in the
engine as people genuinely have different views of what enums are.
One idea that I think may have been mentioned before (and if I recall,
shot down pretty hard) would be to allow people to register cast
callbacks similar to the code below. That would allow people who view
enums as special constants to cast away, and those view enums as
types, to not cast.
This currently would be problematic for the same reason that PHP ini
settings are problematic; without a module or package system, any
settings that affect how the engine behave affect all code that is
run, rather than being limited to just the library that wants to
enable that setting. Which is a problem that keeps rearing it's head.
Maybe someone sponsoring some blue-sky research on how feasible a
module/package system could be, would make addressing problems similar
to the one here be easier to work on.
cheers
Dan
Ack
enum Suit: string {
case Hearts = 'H';
case Spades = 'S';
}
function foo(string $bar) {
var_dump($bar);
}
function cast_backed_enum_to_string(BackedEnum $enum): string {
return $enum->value;
}
register_cast_callback(
BackedEnum::class, // source type
'string', // target type
cast_backed_enum_to_string(...)
);
foo(Suit::Hearts);
// Engine sees we have a BackedEnum and that foo wants a
//
Re: [PHP-DEV] Re: [RFC] [Under Discussion] PDO driver specific sub-classes
Larry Garfield wrote:
> "Create all DB sub-classes?" - I'd say they all should have subclasses, even
> if empty. It's more consistent* that way, and you can then also rely on
> instanceof giving you useful information rather than "well, it's not one of
> the special ones, so beyond that, NFI."
You can get the database type through $db->getAttribute(PDO::ATTR_DRIVER_NAME);
On Tue, 21 Jun 2022 at 15:39, Ben Ramsey wrote:
>
> Is there a reason we shouldn't go ahead and add subclasses for all
database connection types,
YAGNI, and I'm lazy. But mostly, I don't think adding them now
actually helps achieve anything.
Being able to check if the class has specialised methods is useful:
if ($pdo instanceof PDOSqlite) {
$pdo->loadExtension(...);
// do fun stuff with extension here.
}
But for the classes that have no specialised method:
if ($pdo instanceof PDOMysql) {
// What would be of utility here?
}
cheers
Dan
Ack
* How to value being consistent is an aesthetic choice that many other
programmers disagree with me on; "The fundamental guiding force to
bear in mind is whether something is useful or not. Consistency might
satisfy a personal desire for order and simplicity, but most of the
time just having things be consistent is a lower priority than making
choices that are useful." or in this case, less code to write and
maintain.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Under Discussion] PDO driver specific sub-classes
On Tue, 21 Jun 2022 at 10:41, Rowan Tommins wrote: > > The implementation MUST be written by > someone with intimate knowledge of the DBMS in question, or it cannot be > trusted. Well, that rules me out of doing it. > So if we only have a Postgres implementation right now, we should either > implement quoteIdentifier only on PDOPostgres I'll expose it as a method on the PDOPostgres class. Having a quote identifier function on the PDO class itself that does the appropriate thing for all of the databases will be for another RFC, so that is also added to future scope. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Under Discussion] PDO driver specific sub-classes
On Tue, 21 Jun 2022 at 02:26, Larry Garfield wrote: > > Any chance I could convince you to move away from the DSN for the factory? No. That sounds like a challenge for someone who knows about (and cares about) that problem. There's also not enough time to have that discussion before feature freeze. > * "This RFC does not propose adding subclasses for any other PDO database > not listed above. " - But does it presume that future RFCs may do so? This > could currently be read as "let's not do that" rather than what I think the > intent is, which is more "I'm not dealing with that here, talk about that > later." If so, that could be clarified. Yes, I've hopefully made the words clearer. Other points answered in subsequent emails. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] [RFC] [Under Discussion] PDO driver specific sub-classes
Hi, Following previous discussions, here is an RFC to have DB specific classes for PDO. https://wiki.php.net/rfc/pdo_driver_specific_subclasses cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [PHP 8.2] 30 days before feature freeze
On Mon, 20 Jun 2022 at 22:26, Pierrick Charron wrote: > > If you plan to submit a RFC you have > until July 5th to open it for vote so that it can be closed on time. Does that mean tomorrow midnight, or midnight today (aka in about 30 minutes time), is the last chance for RFCs to be announced as under discussion? cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Short Closures 2, aka auto-capture take 3
Hi Larry, Arnaud,
On Mon, 13 Jun 2022 at 13:57, Arnaud Le Blanc wrote:
>
> Auto-capture in PHP is by-value. This makes this impossible. It also makes
> explicit declarations non-necessary and much less useful.
>
Separating off some pedantism from the hopefully constructive comment,
I think some of the words in the RFC are a bit inaccurate:
> A by-value capture means that it is not possible to modify any variables from
> the outer scope:
> Because variables are bound by-value, the confusing behaviors often
> associated with closures do not exist.
> Because variables are captured by-value, Short Closures can not have
> unintended side effects.
Those statements are true for scalar values. They are not true for objects:
class Foo
{
function __construct(public string $value) {}
function __toString()
{
return $this->value;
}
}
$a = new Foo('bar');
$f = fn() {
$a->value = 'explicit scope is nice';
};
print $a; // prints "bar"
$f();
print $a; // prints 'explicit scope is nice';
Yes, I know you can avoid these types of problems by avoiding
mutability, and/or avoiding capturing variables that represent
services, but sometimes those things are needed.
When you are capturing objects that can have side effects, making that
capture be explicit is quite nice (imo). I think the different
emphasis on capturing scalar values or objects might come down to a
difference in style of how different people use closures.
cheers
Dan
Ack
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Short Closures 2, aka auto-capture take 3
Hi Arnaud,
Arnaud Le Blanc wrote:
>
> Following your comment, I have clarified a few things in the "Auto-capture
> semantics" section. This includes a list of way in which these effects can be
> observed. These are really marginal cases that are not relevant for most
> programs.
Cool, thanks.
> Unfortunately, Arrow Functions already auto-capture today, so requiring a
> `use(*)` to enable auto-capture would be a breaking change.
I think there are two things that making this conversation be more
adversial than it could be otherwise:
1. Some people really want implicit auto-capture, while others are
deeply fearful of it. That comes more from the experience people have
from writing/reading different types of code leading them to have
different aesthetic preferences. Trying to persuade people their lived
experience is wrong, is hard.
2. The current situation of having to list all variables is kind of
annoying when it doesn't provide much value e.g. for stuff like:
function getCallback($foo, $bar, $quux)
{
return function($x) use ($foo, $bar, $quux)
{
return $quux($foo, $bar, $x);
}
}
Where the code that returns the closure is trivial having to list out
the full of captured variables does feel tedious, and doesn't provide
any value.
I realise it's annoying when people suggest expanding the scope of an
RFC, however...how would you feel about adding support for use(*) to
the current 'long closures'?
That way, people could choose between:
* Explicit capture of individual variables: function($x) use ($foo,
$bar, $quux) {...}
* Explicit capture of all relevant variables: function($x) use (*) {...}
* Implicit capture of all relevant variables, and fewer letters: fn($x) {...}
People who don't want implicit capture would be able tell their code
quality analysis tools to warn on any use of short closures (or
possibly better, warn when a variable has been captured). People who
do want implicit capture can use the short closures which always have
implicit capture.
cheers
Dan
Ack
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Short Closures 2, aka auto-capture take 3
On Thu, 9 Jun 2022 at 17:34, Larry Garfield wrote: > > That RFC didn't fully go to completion due to concerns over the performance > impact I don't believe that is an accurate summary. There were subtle issues in the previous RFC that should have been addressed. Nikita Popov wrote in https://news-web.php.net/php.internals/114239 > I'm generally in favor of supporting auto-capture for multi-line closures. > > There are some caveats though, which this RFC should address: > > Subtle side-effects, visible in debugging functionality, or through destructor > effects (the fact that a variable is captured may be observable). I think it > nothing else, the RFC should at least make clear that this behavior > is explicitly unspecified, and a future implementation may no longer capture > variables where any path from entry to read passes a write. To be clear, I don't fully understand all those issues myself (and I have just enough knowledge to know to be scared to look at that part of the engine) but my understanding is that the concerns are not about just performance, they are deep concerns about the behaviour. It would produce a better discussion if the RFC document either said how those issues are resolved, or detail how they are still limitations on the implementation. It also probably would have been better (imo) to create a new RFC document. The previous RFC went to vote, even if the vote was cancelled. Diskspace is cheap. Having different (though similar) RFCs under the same URL makes is confusing when trying to understand what happened to particular RFCs. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] DB specific PDO subclasses questions.
On Mon, 6 Jun 2022 at 22:10, Benjamin Morel wrote: > > Hi, what about the ability to load an extension on SQLite? > https://bugs.php.net/bug.php?id=64810 > Basically the equivalent of SQLite3::loadExtension() Thanks, that's exactly the type of thing that should be looked at being added. > [2014-09-17 14:55 UTC] benjamin dot morel at gmail dot com > +1 > Definitely a show-stopper! btw, I admire your patience. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] DB specific PDO subclasses questions.
Hi, I'm looking at making an RFC for subclassing PDO to expose database specific methods in a less magic way, aka implementing what was discussed here: https://externals.io/message/100773#100813 I have two questions for people who use the PDO with SQLite or Postgres 1. Are any of the functions that are specific to those databases horribly designed and need changing? As the functions would be 'copied across' from where they are now, changes could be made without having horrible BC breaks. That is, are any of these functions horrible to use: PDO::pgsqlCopyFromArray PDO::pgsqlCopyFromFile PDO::pgsqlCopyToArray PDO::pgsqlCopyToFile PDO::pgsqlGetNotify PDO::pgsqlGetPid PDO::pgsqlLOBCreate PDO::pgsqlLOBOpen PDO::pgsqlLOBUnlink SQLIte specific functions: PDO::sqliteCreateAggregate PDO::sqliteCreateCollation PDO::sqliteCreateFunction 2. Other than the SQLite blobOpen functionality, does anyone know of any other functionality that is exposed by SQLite or Postgres that isn't currently exposed through the magic PDO methods? cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [Discussion] Expand deprecation notice scope for partially supported callables
On Sun, 29 May 2022 at 16:34, Dan Ackroyd wrote: > > *an incorrect name* Apologies for writing your name incorrectly. That should of course have been addressed to Juliette. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [Discussion] Expand deprecation notice scope for partially supported callables
Hi Julie,
On Sat, 28 May 2022 at 09:22, Juliette Reinders Folmer
wrote:
>
> I admit, I puzzled over this for a little and wanted to take the time to
> respond properly before opening the vote, so I'm delaying the start of the
> vote until beginning of the upcoming week.
Cool.
Actually, I've just realised there is an error in the code in the RFC,
which might be based on a misconception caused by how terrible
callables are. In the code:
if (is_callable('static::methodName')) {
// For valid callbacks, this call will be executed in PHP 8.x,
// but will no longer execute in PHP 9.x.
static::methodName();
}
The string based callable 'static::methodName' is not equivalent to
the syntax* based callable static::methodName().
Using the string version consistently, the equivalent code would be:
if (is_callable('static::methodName')) {
call_user_func('static::methodName', []);
}
which for 8.2 gives the message 'Deprecated: Use of "static" in
callables is deprecated in %s on line %d'. btw trying to call
('static::methodName')(); gives the error message 'Uncaught Error:
Class "static" not found in %s:%d' which is part of the consistency
cleanup done by the previous RFC.
Using the syntax version, the equivalent code that would compatible
with PHP < 8.1
if (is_callable(static::class . '::methodName')) {
static::methodName();
}
Or if support for less than PHP 8.1 can be dropped, using the first
class callable syntax
https://wiki.php.net/rfc/first_class_callable_syntax :
if (is_callable(static::methodName(...))) {
static::methodName();
}
or
$fn = static::methodName(...);
if (is_callable($fn)) {
$fn();
}
Passing the callable round by getting the closure from
static::methodName(...) is probably the safest way of referencing this
type of callable.
None of the syntax based ways of referring to the callable are
deprecated or going to be removed in the foreseeable future.
> for the practical implications of fixing the deprecations,
> there is no difference between the two.
People don't have to fix their code. Deprecations can sit there for as
long as the user likes. If a company decides that paying RedHat for
long term PHP 8.2 support, then they may choose to never fix these
deprecation warning and just silence them instead.
Which leads to a difference of, the deprecation notice when checking
with is_callable and using the callable can be suppressed reasonably
easily:
@is_callable('static::methodName')
@call_user_func('static::methodName', []);
And that's a reasonably sane** thing to do. But the deprecation notice
when passing callables around could happen across many pieces of code,
and there's not a good way of suppressing them, unless you just turn
off deprecation notices entirely.
With the deprecation notice where a user is checking, and a
deprecation notice where it is used, I don't see any value in extra
deprecation notices where the callable is being passed around.
> do you still feel that splitting the vote in two is the best way to go ?
Yes, due to the deprecation notices on type-checks when calling
functions have a higher pain-to-utility that in the is_callable check.
Just guessing, I think the previous RFC thought a deprecation notice
on is_callable isn't needed, as there will be a deprecation notice
when the callable is used. But that probably didn't account for people
being able to mix'n'match callable syntaxes, where is is_callable
check, and the actual use of the callable, are not the same callable.
I also like the deprecation notice on is_callable, as that notice will
be 'closer' to where the bad callable is coming from, so would be
easier to reason about. There's also a rare edge-cases where someone
has a callable that is only called in emergencies (like a disk running
out of space) and so might not have that happen for months. Having the
deprecation on is_callable would help those edge-cases a little.
cheers
Dan
Ack
* Is "syntax based callable" the right name? Better suggestions welcome.
** compared to some stuff I've seen/written.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: ***SPAM*** [PHP-DEV] [Discussion] Expand deprecation notice scope for partially supported callables
Hey Julie,
On Thu, 26 May 2022 at 12:45, Juliette Reinders Folmer
wrote:
>
> I propose to open the vote on this RFC tomorrow.
Before you open the vote, please could you split the voting into two,
one for the is_callable, and one for the callable type check?
Rowan wrote in https://news-web.php.net/php.internals/117670:
> is that passing "99 red balloons" to an "int"
> parameter raised an E_NOTICE in PHP 7.x, so a "callable" parameter
> raising an E_DEPRECATED should be fine.
There's one issue.
When "99 red balloons" is coerced to an int, that is done once, and
then any further int type check will pass. For callables, it's pretty
common to pass them down a stack of code, e.g. similar to:
function foo(callable $fn, $data)
{
$fn($data);
}
function bar(callable $fn, $data)
{
return foo($fn);
}
function quux(callable $fn, $data)
{
return bar($fn, $data);
}
function main(array $data)
{
$fn = get_callable_from_input();
if (is_callable($fn) === false) {
// give some error.
return;
}
quux($data);
}
As far as I understand it, this code would give a deprecation notice
for each call level, which seems quite undesirable. Particularly if
the callable is being used in a loop.
Also, without a patch it's hard to guess what performance impact this
would have. I doubt it would be huge, but it probably wouldn't be zero
either. Performance wouldn't matter for is_callable, as that is
typically only done once per callable, but callable type checks are
done continuously.
cheers
Dan
Ack
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [Discussion] Stricter implicit boolean coercions
On Mon, 16 May 2022 at 16:06, Andreas Leathley wrote: > I have created a preliminary > implementation and an RFC for making implicit boolean type coercions > more strict: > > https://wiki.php.net/rfc/stricter_implicit_boolean_coercions > > With this email I'm starting the two week discussion period. "When discussion ends, and a minimum period of two weeks has passed" Fyi, the two weeks is a minimum, and almost certainly not enough time for subtle BC breaking RFCs like this. > I appreciate your feedback, and if I can improve anything about the RFC I think you should really explicitly list what the changes are in a single table rather than in sentences. > Would you want to know when a value like -375, “false” or NaN > is given to a typed boolean (and coerced to true) in a codebase? Yes. Which is why I always use both PHPStan and Psalm to detect those types of things where those types of bugs are important. Also, strict mode is great. > In one application recently I actually had the string "false" (coming > from a form transmission) being passed to a boolean argument and leading > to true, which definitely was unintended. But "false" is a perfectly sensible thing to pass as a string in an API (as HTTP is a string based protocol). As is 'faux' if your API is used by French speaking programmers. You need an layer of code that converts from strings to the precise types your API needs, rather than just passing values straight through. > if it mainly reveals bugs in applications, couldn't that > be enough of a reason in favor of it? Although this change would probably detect some bugs, it's not at all obvious that the amount of pain would be worth it. A lot of applications out there aren't being constantly developed. Instead they are in maintenance mode, where there isn't a programmer dedicated to constantly work on it. There would be lots of function calls to check, and some of them would need code to be modified to maintain the existing behaviour. And all of that would seem to be subtle work, prone to mistakes. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Body-less methods
Hi Rox,
On Mon, 23 May 2022 at 15:49, ROX wrote:
>
> I focus on Developer eXperience and language consistency.
When you have karma to write the RFC, you should probably include in
the text why having an extra piece of capability in the language (i.e.
one more thing to learn), that only saves two characters is a better
DX than the current situation.
In particular, as it's a slightly different meaning from the other
places where no body is allowed, as Guilliam Xavier wrote in
https://externals.io/message/114324#114334:
> To me ; means not "empty body" (that's {}) but really "no definition,
> only declaration" (or "no body, only signature", and also "no code
> executed"), i.e. an abstract method (either explicitly declared so in a
> class, or implicitly in an interface).
It's not obvious to me that body-less methods would be 'consistent'.
btw, there's a reasonable chance that whether people like the general
idea or not is an aesthetic choice, and so people will either like the
idea or not based on instinct rather than 'logic'. By spelling out why
you think it's better, rather than assuming people will agree with
that, would probably give the RFC the best chance of succeeding.
cheers
Dan
Ack
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] PHP Community to support Ukraine and help to stop Russian agression
Hi Victor, I have strong feelings about the war and that people should be taking whatever personal action they can (check my pinned tweet, @MrDanack), but: i) PHP Internals is for discussion of PHP internals. ii) We have contributors on both sides of the conflict. There are also many other causes that people can or should be supporting. Having conversations about what position the PHP project should take for reach of those causes is a conversation that takes away time + energy from PHP. iii) Adding flags help when issues are little known or obscure, but aren't useful when a cause is well known. Except maybe make people feel a little bit better about "having done something". It possible for projects many fewer contributors than PHP does to "speak with a single voice". E.g. there appear to be 3 main contributors to JUnit. But projects the size of PHP need to either stay apolitical or to have a strong executive team that can make decisions on behalf of the project. I do urge everyone to take effective action that they can personally do themselves, but the suggestion is not likely to help, and is likely to turn a shouting match very quickly. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] SensitiveParameterValue serialization behavior
On Thu, 24 Feb 2022 at 14:11, Tim Düsterhus, WoltLab GmbH wrote: > > I see two possible options to remediate this issue: > > --- > > 1. Disallow both serialization and unserialization. > > This will make the serialization issue very obvious, but will require > adjustments to exception handlers that serialize the stack traces. That sounds the best option. Yes, people who serialize/unserialize stack traces will need to take into account the new behaviour, but they will need to do that anyway, and it's better for something to fail early, when the data is serialized rather than it happen later when someone goes to use that data. Programs continuing when they have already failed is Bad™. > Allow unserialization, but poison the unserialized object and > disallow calling ->getValue() on it. That sounds like something to be instantly added to the list of PHP Sadness. > I theoretically could add an additional public function isPoisoned(): bool as > well. To me, that sounds like a workaround needed by a bad design aka a hack. Guilliam Xavier wrote: > to avoid potentially breaking existing code. Technically, all existing code will continue to run, as no-one is currently using SensitiveParameter and so that code will continue to run. When people start using that feature, then yes they will need to make sure that any stack serializer is aware of the new feature. But that doesn't sound like a huge problem to me. In general, I think we should only add surprising and awkward apis when there is a really strong reason for doing so, not because there might be a problem. If it's left as unserializable for now, people would have the opportunity for saying why it needs to be relaxed later, aka "no is temporary, yes is forever" for features. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC [Discussion]: Redacting parameters in back traces
On Tue, 11 Jan 2022 at 09:11, Tim Düsterhus, WoltLab GmbH wrote: > > So basically all the other languages I researched do not provide > arguments within back traces. Uh, that kind of suggests that providing arguments at all is a mistake, and that removing could be the way to go. I mean other than everyone complaining about the BC break. An awkward question; why is this hard-coding of the behaviour dependent on a new attribute the correct thing to do? PHP allows people to set_error_handler() to process errors how they like. Conceiveably, allowing users to set a custom function to redact data from stack traces would allow users to inspect and redact the parameters however they like. Why is adding a special attribute that is recognised by the PHP engine itself the right thing to do? To be clear, I can think of at least two reasons. But also, I think every attribute that is proposed to be added to PHP core, needs to have the reasons why it's the right thing to do listed. If nothing else, it will help to reject attributes in the future if they don't have the same strong justifications. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC [Discussion]: Redacting parameters in back traces
Hi Tim, On Mon, 10 Jan 2022 at 14:05, Tim Düsterhus, WoltLab GmbH wrote: > > this is a follow-up for my "Pre-RFC" email from last Friday, January, 7th. > > https://wiki.php.net/rfc/redact_parameters_in_back_traces > How do other languages handle this problem? Or how do they avoid it in the first place? >From the RFC: > Specifically the back trace collection should be updated to use an object of > class > \SensitiveParameter as the value for all parameters that are marked with the > \SensitiveParameter attribute. To methese words are not clear. Does the following sentence say the same thing? "When the backtrace is generated, any parameter that has a 'SensitiveParameter' attribute will not have it's value stored in the backtrace, but instead will be replaced with an SensitiveParameter object. If so, the RFC could be updated to be clearer.if not, then the RFC should be updated to be clearer. Also, having parameters replaced with another type doesn't seem obviously correct. There should probably be some words justifying why that is the correct thing to do, rather than just replacing any values with "REDACTED***" or other simple behaviour. > On shared web hosting, the customer might not be able to configure it. My personal opinion is that shared web hosting shouldn't be a thing that exists in 2022. And definitely shouldn't be used for anything where secrets need to be maintained. Yeah shared hosts might have a DB they can connect to, but those credentials should only be usuable from the shared host to the DB. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] User Defined Operator Overloads (v0.6)
On Fri, 17 Dec 2021 at 18:36, Stanislav Malyshev wrote: > > When reading > this code: $foo * $bar - how do I know which of the ways you took and > where should I look for the code that is responsible for it? When I see > $foo->times($bar) it's clear who's in charge and where I find the code. > Terse code is nice but not at the expense of making it write-only. Well, there's only two places to look with operator overloads, but yes you're right, using operator overloads for single operation is not a good example of how they make code easier to read. The more complicated example from the introduction to the RFC https://wiki.php.net/rfc/user_defined_operator_overloads#introduction shows how they make complex maths easier to read. The exact position of where that trade-off is 'worth it' is going to be different for different people. But one of the areas where PHP is 'losing ground' to Python is how Python is better at processing data with maths, and part of that is how even trivial things, such as complex numbers, are quite difficult to implement and/or use in userland PHP. Stanislav Malyshev wrote: > And again, what's the intuitive > difference between operators +=+@-+ and ++--=!* ? That's not part of the RFC. There's enough trade-offs to discuss already; people don't need to imagine more that aren't part of what is being proposed. > I have encountered > toolkits where the authors think it's cute to define "+" to mean > something that has nothing to do with mathematical addition Rather than leaving everyone to make the same mistakes again, this RFC might be improved by having a list of stuff that it really shouldn't be used for. At least then anyone who violates those guidelines does so at their own risk. Having guidelines would also help junior devs point out to more senior devs that "you're trying to be clever and the whole team is going to regret this". I started a 'Guidelines for operator overloads' here (https://github.com/Danack/GuidelinesForOperatorOverloads/blob/main/guidelines.md) - if anyone has horrorible examples they'd like to add, PR's are welcome. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] User Defined Operator Overloads (v0.6)
On Thu, 16 Dec 2021 at 08:24, Pierre wrote: > > > If the names are a problem, why not registering those using an attribute > ? If there is a strong reason to use attributes, then the argument should start from there. Starting from "well we could just use an attribute" and then putting the pressure on other people to find a reason to _not_ use an attribute, is a terrible design process. Every language that has annotations ends up with far too many of them; PHP is likely to end up with too many of them also. The time to push back against using them is now, not when the damage has been done. But to repeat, I don't think the names of magic methods are a problem. Documenting that 'the name refers to the operator sigil, not to what the function does', avoids it being a problem to be solved. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] User Defined Operator Overloads (v0.6)
On Thu, 16 Dec 2021 at 12:21, Andreas Hennings wrote:
> Methods and functions have searchable and clickable names. Operators don't.
> The "searchable" applies to grep searches in code, but also google
That's one of the reasons why I prefer a magic methods based approach.
function __plus(...){}
can be searched for...and for future scope, something like:
function __union(...){}
is more self-documenting (imo) than:
operator ∪(...){}
> Lack of real parameter overloading
> Unlike C++ (or C?), we don't have real method/function overloading
> based on parameters.
Java is probably a better comparison language than C.
I have a note on the core problem that method overloading would face
for PHP here: https://phpopendocs.com/rfc_codex/method_overloading
But although they both involved the word 'overloading', operator
overloading, and method overloading are really separate features.
> we cannot have the conditional type hints.
btw you can just say 'types'.
Unlike some lesser languages, in PHP parameter types are enforced at
run-time; they aren't hints. I believe all references to hints (in
relation to types at least) have been removed from the PHP manual.
cheers
Dan
Ack
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] User Defined Operator Overloads (v0.6)
On Sat, 11 Dec 2021 at 19:13, Jordan LeDoux wrote: > > I *think* that all of the things you mentioned will need similar > updates to work correctly with this RFC even if it was done > with plain old magic methods instead. No, that's not true. Codesniffer and all the other tools parse magic methods just fine. Stuff like the coverage notation for PHPUnit would understand `@covers BigNumber::__plus` just fine. The main piece of work each of them would need to do to support this RFC, if it was based on magic methods, is being able to understand that objects can work with operators: ``` $foo = new BigNumber(5); $foo + 5; // Check that BigNumber implements the magic method __plus ``` That is far less work than having to add stuff to parse a new way to declare functions. Jordan LeDoux wrote: > > Danack wrote: >> # "Non-Callable - Operand implementations cannot be called on an >> instance of an object the way normal methods can." >> I think this is just wrong, and makes the RFC unacceptable to me. > > First, you can still get the closure for the operator implementation > from Reflection if you really, really need it. Sorry, but I just find that a bizarre thing to suggest. Introducing a new type of function that can only be called in a particular way needs to have really strong reasons for that, not "oh you can still call it through reflection". I think you've taken the position that using the symbols are cool, and you're reasoning about how the RFC should operate from decision. I'm not sure I can make a reasonable argument against it that you would find persuasive, but to me it's adding a non-trivial amount of complexity, which tips the RFC from being acceptable, to not. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] User Defined Operator Overloads (v0.6)
On Sat, 11 Dec 2021 at 17:46, Larry Garfield wrote:
>
> Using symbols, however, would (with some future extension to make it
> extensible) allow for:
I don't get how it's easier, other than being able to skip naming the
symbol name. e.g. adding union and intersection operators
function __union(...){}
function __intersection(...){}
vs
operator ∪(...){}
operator ∩(...){}
In fact, I find one of those quite a bit easier to read...
Larry Garfield wrote:
> It uses effectively the same operator sigil, though.
Yes, that's what I was trying to say.
Danack wrote:
> The name of the function (e.g. __add) always refers to the symbol used
> where it is used, not what it is doing.
If the naming is taken from the sigil, then it's always appropriate.
So if operator * has the magic method __asterisk instead of __mul, it
avoids any suggestion of what the operation actually means for the
object.
btw, I don't really care about this naming problem. My concern is that
it's being used as a reason for introducing a special new type
function, when it's really not a big enough problem to deserve making
the language have special new syntax.
cheers
Dan
Ack
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] User Defined Operator Overloads (v0.6)
On Sun, 12 Dec 2021 at 08:55, James Titcumb wrote: > > The only mitigation for unnecessary complexity I can think of is to force > overloaded operators to be "arrow functions" to encourage only minimal > code, e.g. > The 'valid' use-cases for this aren't going to minimal pieces of code. Things like a matrix object that supports multiplying by the various things that matrices can be multiplied by won't fit into an arrow function. Also, I fundamentally disagree with making stuff difficult to use to 'punsish' users who want to use that feature. If you want to enforce something like a max line length in a coding standard, or forbidding usage of a feature, that is up to you and any code style tool you use. > I just think the desire to use this in ways it shouldn't be > used will be too great, It might be an idea to add a list of bad examples to the RFC, so people can refer to how not to use it, rather than each programming team having to make the same mistakes. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] User Defined Operator Overloads (v0.6)
Hi Jordan, On Thu, 9 Dec 2021 at 20:12, Jordan LeDoux wrote: > > Hello internals, > > I last brought this RFC up for discussion in August, and there was > certainly interesting discussion. Since then there have been many > improvements, and I'd like to re-open discussion on this RFC. In general I'm in favour of this RFC; a few months ago I was programming something and operator overloads would have been a good solution, but then I remembered I was using PHP, and they haven't been made possible yet. However.I think the new 'operator' keyword is probably not the way to go. Although it's cute, it has some significant downsides. There are quite a few downstream costs for making a new type of methods in classes. All projects that analyze code (rector, codesniffer, PHPStorm, PhpStan/Psalm, PHPUnit's code coverage annotations etc) would have to add a non-trivial amount of code to not bork when reading the new syntax. Requiring more code to be added and maintained in PHP's builtin Reflection extension is also a cost. That's quite a bit of work for a feature that has relatively rare use-cases. I just don't agree/understand with some of the reasoning in the RFC of why using symbols is preferable. "In such a situation, using magic methods would not be desired, as any combination of symbols may be used for the new infix. The restrictions on function names, such as needing to reserve the & to mark a function as being by-reference, would place limitations on such future scope." I don't get this. The magic methods in previous drafts of the RFC don't have a problem with & as the methods are named with 'two underscores' + name e.g. __bitwiseAnd. That does't appear to cause a problem with an ampersand? "By representing the implementations by the symbols themselves, this RFC avoids forcing implementations to be mislabeled with words or names which do not match the semantic meaning of that symbol in the program context. The name of the function (e.g. __add) always refers to the symbol used where it is used, not what it is doing. If the code is `$a + $b` then that is an addition operator, when the code is read. If I was reading the code, and I saw that either $a or $b were objects, I would know to go looking for an __add magic method. " '// This function unions, it does not add'" Then that is probably an example of an inappropriate use of operator overloads, and so shouldn't be used as a justification for a syntax choice. # "Non-Callable - Operand implementations cannot be called on an instance of an object the way normal methods can." I think this is just wrong, and makes the RFC unacceptable to me. Although most of the code I write is code that just performs operations as I see fit, some of the time the operations need to be driven by user data. Even something simple like a calculator-as-a-service would need to call the operations dynamically from user provided data. I also have an aesthetic preference when writing tests to be explicit as possible, rather than concise as possible e.g. $foo->__add(5, OperandPosition::LeftSide); $foo->__add(5, OperandPosition::RightSide); instead of: $foo + 5; 5 + $foo As I find that easier to reason about. cheers Dan Ack /congratulations on stunning the audience into silence otherwise though. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Automatic implementation of Stringable may conflict with old, untyped arginfo declarations
On Wed, 8 Dec 2021 at 16:02, Jeremy Mikola wrote: > > > We haven't explored using stubs, but I'll keep that in mind. ... > (which we plan to do since we finally dropped support for PHP > 7.1). > FYI, the stub files maintain #ifdef info through their processing, which allows some useful shenanigans* e.g.: https://github.com/Imagick/imagick/blob/86d95fed787d60db110ccfeb2d89ec53f1d1f5f7/Imagick.stub.php#L168-L182 https://github.com/Imagick/imagick/blob/86d95fed787d60db110ccfeb2d89ec53f1d1f5f7/Imagick_arginfo.h#L748-L778 So the stubs are used to generate arg info for Imagick from PHP 5.4 to 8.1, across lots of versions of ImagickMagick. I'm finding managing function signatures in a PHP file, in standard PHP format, is a lot nicer than maintaing that info in C files. cheers Dan Ack * Though, tbh, I wished I'd known about /** @generate-legacy-arginfo */ before doing some of the hacks in the Imagick regen_arginfo.sh script. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Why do PHP 8.1 extensions need PHP headers during make install (worked in <8.1)?
On Thu, 9 Dec 2021 at 19:28, Dan Ackroyd wrote: > > Is this intentional? If so, could someone explain the purpose of the > > change? > > Probably to make the build process less flaky, by explicitly checking > dependencies, so that there are fewer instances of "stuffs not > working.I guess I'll do a make clean and see if that helps". > And of course I find the commit just after sending previous email: commit - https://github.com/php/php-src/commit/c4d508c2bc09860bfa15b7f520e0ba68425acfc1 reasoning - https://github.com/php/php-src/pull/6693 cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Why do PHP 8.1 extensions need PHP headers during make install (worked in <8.1)?
On Wed, 8 Dec 2021 at 15:25, David Zuelke via internals wrote: > > That doesn't work with PHP 8.1 anymore - the Makefile generated by > phpize now contains an include directive at the top level (near the > bottom), e.g.: > > -include src/php_raphf_api.dep The file src/php_raphf_api.dep is created when the source code is compiled. It creates a list of which files were used in the compilation of a C file. In this case src/php_raphf_api.c The '-include' directive apparently allows for a file to be listed, but not error when it doesn't exist, apparently: https://www.gnu.org/software/make/manual/html_node/Features.html so on a fresh cleaned build, it shouldn't make any difference. > Which lists not only the extension's headers, but also all of PHP's > (in include/main, include/Zend, and so forth): Yes. Those are the files that need to be present to compile that source code file. It's used to check to see if a C file should be recompiled, as one of it's dependencies has changed. The dep file is also deleted when doing make clean. It doesn't appear to me that the change to the phpize and the dep file is affecting other peopleI think the problem you're seeing is something unique to your build process. In particular: 1. Are you doing a make clean, or is there a chance of left over files from a previous build? 2. Why are you (as far as I understand) deleting the PHP files in `5) rm -rf $installdir`, before compiling the extension? The command `make install` does a check on whether anything needs recompiling.and I believe it's failing because the files it's trying to check no longer exist. > Is this intentional? If so, could someone explain the purpose of the change? Probably to make the build process less flaky, by explicitly checking dependencies, so that there are fewer instances of "stuffs not working.I guess I'll do a make clean and see if that helps". cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: [VOTE] Deprecate dynamic properties
On Fri, 26 Nov 2021 at 00:55, Brady Wetherington via internals wrote: > > That's 1.5 million hours, which is 171 developer-years. If we're going to imagine numbers; there are 6 million PHP developers in the world*. If on average they each lose just 1 hour per year by making typos and accidentally creating a properties dynamically, that's 6 million hours, or 684.93 years! So the value delivered by this change would be 4 times the cost just in the first year. And then every year after that it's pure benefit. > What I'm scared about is about our 42 dependencies in composer.json, How about sponsoring each of your dependencies some money, to encourage them to check if their code is compatible after this change, and fix it if it isn't. If a dependency is used by even just 1000 companies, and each of those companies chips in $50, then $50,000 will fund many months of work on that dependency. > probably more, if we try to include work-life balance and whatnot :P Most open source is done by people in their free time. Because companies keep refusing to fund open source. > might be stuck on a framework or something that's no longer being updated, Having companies sponsor open source projects makes it less likely they will be abandoned. cheers Dan Ack * https://www.theregister.com/2021/04/26/report_developers_slashdata/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Deprecate dynamic properties
Hi Juliette, On Mon, 15 Nov 2021 at 23:36, wrote: > > I've been asked to post the link to the Twitter discussion in this > thread for visibility. > > The Twitter thread generated, and is still generating, quite a lot of > discussion, I'm not going to quote from the Twitter thread partly as lot of that discussion isn't that pleasant. To be clear, this change isn't being proposed to annoy open source maintainers, it's proposed because people think it will make the language better, to a great enough value to be worth the BC break. But also, a lot of that thread is about the experience of being an open source developer is absolutely terrible due to many factors including: * an almost complete refusal of companies to sponsor work. * people who work for companies that use open source having an attitude of entitlement to 'gold level support', and will very quickly start using emotionally manipulative language e.g. "if you cared about this project you'd work harder on it". * a lack of new contributors to open source. I completely understand how all of things are pretty aggravating. It's particularly galling when a maintainer tries to get some funding, e.g. by holding back a release targetting a new version of PHP, other people will undermine that effort by forking the library and doing just enough to get it working, but not committing to do any future work. I'm in the lucky position that because PECL is so hard to use (and gate-keepered as to who can use it), that I was able to hold off doing the release of Imagick with PHP 8.0 support until a couple of companies stepped up with a (greatly appreciated) non-trivial amount of sponsorship. What the future holds for open source is unclear to me. And it's not at all obvious that open source isn't a morally wrong thing to do, as to a large extent it seems to rely on individuals subsidising for profit companies. However I don't think that slowing down the improvements in PHP core itself is an appropriate response to companies refusing to pay to support the projects they rely as a business on. I do recommend anyone who has an open source project to: * make sure you have github sponsors or other sponsoring services setup. * ask for payment for work done previously. If you've created a library that companies are dependent on, it's okay to refuse to work on it until there is a decent amount of support for that work done. You don't have to commit to doing new work until the project has a sustainable rate of sponsorship. * compare the amount of money you're getting for a project to the commercial rates for developers, and not to how much cup of coffee is. * Feel free to forward any cash you don't feel justified keeping to other opensource projects particularly upstream dependencies or tools. Or if you don't have enough time to work on that project yourself, feel free to ask for enough money to pay someone else to work on it. Once those done, it's perfectly acceptable to put a project on 'strike' until it's funded adequately and refuse to release new versions to accomodate changes in PHP. I know that saying 'no' to users is draining as they so often try to guilt maintainers into doing work for free. If anyone would like me to help explain to users "your company needs to start sponsoring this project before this project will acknowledge this issue", in any of their projects repos, please ping me on twitter https://twitter.com/MrDanack cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Deprecate dynamic properties
On Fri, 12 Nov 2021 at 19:00, Matthew Weier O'Phinney wrote: > > Our IDEs, coding standards, and static analysis tools can already flag > these things for us, helping us catch them early. Hell, unit testing will > find these for us, when a test fails due to a value not being set in a > property that we expected. New users don't have these tools. And a lot of 'experienced' developers don't have those tools either. A disconcerting number of developers don't even use source control. Although exactly which users a language should be designed to cater for, I don't think an answer of "those who have used it long enough to setup static analysis tools" is a great one. But even when people have static analysis tools setup, they are slow to run. Andreas Heigl wrote: > So while the static analysis is one possibility, the other > one is writing appropriate tests. > . > So the mistakes-part would be easy to handle. This is not my experience. My experience is the same as Matthew Brown wrote: > I have heard newcomers express literal > surprise when discovering this for the first time, and not in a delighted > way. People encounter the 'feature' of PHP not warning or erroring on dynamically creating a property by accident most of the time. They make a typo in their code and wonder why their code isn't working as expected. Even though I use an IDE, and have pretty comprehensive static analysis and tests, this feature keeps biting me often enough that I created a trait to stop it (https://github.com/Danack/Params/blob/main/lib/Params/SafeAccess.php) which I normally copy and paste into each project. Matthew Weier O'Phinney wrote: > Making this fundamental change to the language means, however, that a lot > of things that we were previously able to do that "just worked" now raise a > deprecation notice, and, later, a compilation error... unless we make a > change to our already working, fully functional code. This is the trade-off that all RFCs that have BC breaks have: 1. it's going to cause some work for projects that deliberately use this feature. 2. it's going to save time/improve the developer experience for people in the future If PHP was a dead language that fewer people are starting to learn, and few new projects are started using it, then option 1 is probably the side to prioritise. But I'm hoping that PHP isn't a dead language, and that the future benefit from not having to spend so long debugging their code is greater than a small amount of BC break. For the people who are currently voting 'no', I'd ask are you really sure that the amount of work adding "#[AllowDynamicProperties]" to the classes you want to keep having dynamic properties is really that much time compared to the time that would be saved by having PHP itself give an error when a user accidentally creates a dynamic property? cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Locale-independent case conversion
On Thu, 25 Nov 2021 at 05:05, Tim Starling wrote: > > Voting is now open for my RFC on locale-independent case conversion. > It seems popular, and likely to pass, but I voted no as the "Backward Incompatible Changes" section is missing which makes it hard to evaluate the impact. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Sponsor link on github.com/php
On Tue, 23 Nov 2021 at 10:43, Kim Hallberg wrote: > > For GitHub sponsors the organisation, in this case PHP, would need to connect > a > bank account directly to the organization. I believe Nils is referring to this: https://blog.opencollective.com/double-the-love/ Sara wrote: > An alternative may be to link to the various foundations from php.net (and > github.com/php) with some text stating that they are all independent > organizations One of the advantages of having the repos split on github is that each repo could list the most appropriate sponsor links for the people doing the work on that repo. For example php/doc-fr could have a completely different place to sponsor, rather than the 'PHP Foundation', to avoid burdening the 'PHP Foundation' with managing doc-fr finances. Kim wrote: > PHP has always remained unbiased in the past for things of this nature. PHP has always been rubbish at: * long term support of versions. * long term support of tools e.g. is PEAR/PECL dead or not? bugs.php.net * having enough contributors to the docs and extensions. Pointing to how things have been done in the past is a less strong argument than you might think. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Migrating to GitHub issues
On Mon, 15 Nov 2021 at 09:47, Derick Rethans wrote: Derick wrote: > I think it is a mistake to decide on a whim to move over to GitHub > issues without having evaluated anything else. Maybe avoid being insulting about other people's decision making process? I'm pretty sure that Nikita doesn't make that many decisions on a whim, and that he has spent quite a bit of time over the past couple of weeks/months figuring out how it would work, and getting a test repo setup with the new issue templates. And I also believe he has spent signification time evaluating alternatives, but they all come up across the same problem listed in the RFC: "The requirement for an alternative would be that a) it is hosted (i.e. the PHP project does not need to maintain infrastructure for it), b) has good GitHub integration and c) is “sufficiently better” than GitHub issues to make it worth using a separate product." I don't think the vendor lock-in concern is that great. If Microsoft actually starts acting evil again, to the extent that we need to stop using Github for either code or issues, then we would be able to move again. The lock-in on github doesn't appear to be worse than bugs.php.net. In fact, it's far more likely that anything we would move to is going to have an "import from github" button, than anything having an "import from bugs.php.net" button. > This jump to GitHub Issues feels rushed, The topic has been discussed for at least 6 months: https://news-web.php.net/php.internals/114330 That seems like quite a bit of time for people who would prefer to avoid github to evaluate the alternatives and write out a plan. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Migrating to GitHub issues
On Mon, 15 Nov 2021 at 09:56, Hans Henrik Bergan wrote: > > if hosting it ourself is a priority, No, quite the opposite. The PHP project is pretty terrible at running infrastructure, as infrastructure needs to have people available to work on it immediately when there are issues, which is not a good match a volunteer project. There is also the problem that a lot of maintenance needed for sites (or things like PEAR/PECL) are very boring, and so they are allowed to rot for years. Even if we had the resources to host something ourselves, doing so would come at an opportunity cost of not doing something that provides better value for the time. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Migrating to GitHub issues
On Tue, 2 Nov 2021 at 14:19, Nikita Popov wrote: > > I'd like to formally propose to use GitHub for PHP implementation issues as > well: https://wiki.php.net/rfc/github_issues In general, yes please. The only bit I'll chime in on is: > bugs.php.net will remain active for the following purposes: > Reporting of issues against PECL extensions. (We may want to discontinue > this as well. Many actively maintained extensions already use GitHub issues > rather than bugs.php.net.) Providing a bug reporting site was a useful thing to do 23 years ago, as it would have been either expensive or time consuming for each project to set up their own. It doesn't seem as sensible now as: * Having bugs.php.net remain open for some bits of PHP, but not others, would be confusing for users. * Most extensions are hosted on a platform that already provides issue tracking - though it seems quite a few extensions (including Imagick) have not realised that there is a bug tracking setting that can/should be updated on pecl. * There's an ongoing issue of extensions becoming unmaintained over time. If people are opening bugs on the PHP issue tracker, it's natural for them to have an expectation that someone from the PHP project would work on that issue at some point. So unless someone has a strong argument for keeping the bugs.php.net open for PECL extensions, I think it shouldn't be. btw it would probably be useful to dump out a list of where to report bugs for different extensions and put that as a page on bugs.php.net though. If nothing else, Google thinks Imagick is an alias for ImageMagick far too often and sometimes pecl.php.net is unresponsive. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Function list declaration syntax?
On Tue, 5 Oct 2021 at 18:47, Mike Schinkel wrote:
> Consider the `Type` class[3] in the `SebastianBergmann\Type` namespace. It
> contains 60 lines of function declaration to define 14 functions that all
> return `false`.
PHP allows you to define functions on one line:
function isCallable(): bool { return false; }
function isFalse(): bool { return false; }
function isGenericObject(): bool { return false; }
If you don't like having functions take up lots of lines, it's easier
to just not follow that PSR guide line on formatting, rather than
modify the language.
cheers
Dan
Ack
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Spam on bugs.php.net
On Mon, Oct 4, 2021 at 1:20 AM Stanislav Malyshev > I'm not sure if anyone is maintaining it right now - but > it'd be nice to have changes to counter that The code for bugs.php.net has a huge amount of tech debt and is a scary thing to touch. On Mon, 4 Oct 2021 at 09:46, Nikita Popov wrote: > part of the motivation to switch to > GitHub Issues (which requires authentication and thus can be moderated > effectively). When this was raised before, people seemed to have two concerns: * not having a single linear history of bugs. * having to risk losing a whole load of bug reports if the PHP project ever moves away from using Github. If we: * Close bugs.php.net to all new bugs, except maybe those created by logged in php.net accounts. * Prevent any non-logged in users from commenting. * Mirror any new bugs created on github to bugs.php.net with the appropriate packages etc. * Mirror comments + updates from github to bugs.php.net. that would address both those concerns. Github now supports Templates* for issue forms, these could be setup so users still select "Package affected", "PHP version" etc I'm prepared to do that work...if it sounds like a sensible plan to others and the work wouldn't be wasted. cheers Dan Ack * https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/syntax-for-issue-forms -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Random Extension 3.0
Go Kudo wrote: > Dan Ackroyd wrote: >> you can _simply_ include ext/random/random.h." sounds pretty >> dismissive of causing possibly unneeded work for downstream projects. > > The point I was trying to make was that while BC Breaks do occur, they are > very easy to solve. I've found it useful to think about "value = benefit minus cost". I was calling out that it seems to be that this is a change you want to do for aesthetic reasons and are justifying it by trivialising the work involved. i.e. it has a tiny benefit that only has a positive value if the cost is also tiny. Although the change is simple: * Any code base that includes standard/php_rand.h won't compile, and people will have to find out what changed. Even though the fix may be easy to implement, each of those people will have to figure it out for themselves. * quite a few people will have to learn (or relearn) how to use #if to compare PHP version to include either standard/php_rand.h or random/php_random.h if they want their code to work on more than 1 PHP version. * it makes more work for downstream distributors of PHP, as their patches (including security patches) will need to be moved around. If there's a good reason to move stuff around, then fine, but avoiding creating extra work downstream is worth doing. And possibly is a hot topic right now. You could probably avoid a lot of downstream work by leaving a stub file at standard/php_rand.h that includes random/php_random.h. cheers Dan Ack btw, if you could please avoid top-posting, that would be appreciated: https://github.com/php/php-src/blob/master/docs/mailinglist-rules.md "Do not top post. Place your answer underneath anyone you wish to quote and remove any previous comment that is not relevant to your post." -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
