Re: [PHP-DEV] [Discussion] "Internal" attribute and warning
Hey Robert. Am 19.05.24 um 09:38 schrieb Robert Landers: On Sat, May 18, 2024 at 9:11 PM Andreas Heigl wrote: Am 18.05.24 um 19:46 schrieb Robert Landers: On Sat, May 18, 2024 at 7:38 PM Andreas Heigl wrote: Hey all. Am 18.05.24 um 16:00 schrieb Robert Landers: [snip] I guess that depends on what you mean by "break the code." Many people turn warnings into exceptions, and for those people this will effectively break their code. Some people may choose to ignore it one way or another, but that would be up to them. The idea isn't to break people's code though, it's to provide a way to mark very-malleable APIs in libraries. Maybe, "Internal" is a bad name for this, but it's the most logical. The trouble I see is that there are two kind of people: Those that care about such things and those that don't. Those that care about such things will already find these issues during static analysis. Those that don't care will not turn errors into exceptions but instead have error-reporting set to 0 That's why I am hesitant in adding this to the engine but instead would love to see this as part of userland maintained static analyzers. [snip] Hey Andreas, I don't think this is a useful way to look at it. Otherwise, what is the point of making any error or warning? Static analysis is useful, but there's a lot of things it misses, especially when dynamic calls start happening. Probably the most interesting question is about our and the users expectation when declaring respectively using an internal entity. Is it's use something that should just pop up in the logs? And if so: What does it mean? Is using an internal entity outside it's expected usage actually an error? After all an error should be used when the application hits an issue preventing one or more functionalities from properly functioning. We can not really say that is happening just because someone uses a function in a place we do not expect it to be used. It might still work. But from the point of view of the person declaring that internal entity muich more should happen. The code shouldn't work AT ALL any more. Someone is using my code in a way that I did not intend it to be used, so the whole application should break. But we can not assert that. So by having a look at the expectations of the different parties we can calibrate our intentions and then see how we can provide the best solution. And to me in that case the best solution would not be to enforce this on the language level but to leave it to static analysis. Because I know how inventive people can get to use things in ways they are not supposed to be used. Search for `composer unfinalize`... Cheers Andreas -- ,,, (o o) +-ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +-+ | https://hei.gl/appointmentwithandreas | +-+ | GPG-Key: https://hei.gl/keyandreasheiglorg | +-+ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [Discussion] "Internal" attribute and warning
Am 18.05.24 um 19:46 schrieb Robert Landers:
On Sat, May 18, 2024 at 7:38 PM Andreas Heigl wrote:
Hey all.
Am 18.05.24 um 16:00 schrieb Robert Landers:
Hello internals,
I've been thinking about having an "internal" attribute that will emit
a warning if called from outside it's left-most namespace.
It might look something like this:
namespace MyCompany\PackageA {
#[\Internal] function doStuff() {}
}
namespace OtherCompany\PackageB {
\MyCompany\PackageA\doStuff(); // warning emitted
}
namespace MyCompany\PackageB {
\MyCompany\PackageB\doStuff(); // left-most part of namespace
matches, no warning
}
This would allow for library maintainers to mark internal constructs
as such and provide users with feedback that they are using code that
may be changed without any notice.
Any thoughts?
I do like the idea in general of being able to mark certain things as
internal to a certain namespace.
My question is more in the direction of: If we are not enforcing
breaking the code but merely emit a warning then that is IMO not
something that we need to implement on the language level. People will
still be able to use the internal method and just ignore the warning.
I guess that depends on what you mean by "break the code." Many people
turn warnings into exceptions, and for those people this will
effectively break their code. Some people may choose to ignore it one
way or another, but that would be up to them. The idea isn't to break
people's code though, it's to provide a way to mark very-malleable
APIs in libraries. Maybe, "Internal" is a bad name for this, but it's
the most logical.
The trouble I see is that there are two kind of people: Those that care
about such things and those that don't.
Those that care about such things will already find these issues during
static analysis.
Those that don't care will not turn errors into exceptions but instead
have error-reporting set to 0
That's why I am hesitant in adding this to the engine but instead would
love to see this as part of userland maintained static analyzers.
Cheers
Andreas
--
,,,
(o o)
+---------ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org |
+-+
| https://hei.gl/appointmentwithandreas |
+-+
| GPG-Key: https://hei.gl/keyandreasheiglorg |
+-+
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: [PHP-DEV] [Discussion] "Internal" attribute and warning
Hey all.
Am 18.05.24 um 16:00 schrieb Robert Landers:
Hello internals,
I've been thinking about having an "internal" attribute that will emit
a warning if called from outside it's left-most namespace.
It might look something like this:
namespace MyCompany\PackageA {
#[\Internal] function doStuff() {}
}
namespace OtherCompany\PackageB {
\MyCompany\PackageA\doStuff(); // warning emitted
}
namespace MyCompany\PackageB {
\MyCompany\PackageB\doStuff(); // left-most part of namespace
matches, no warning
}
This would allow for library maintainers to mark internal constructs
as such and provide users with feedback that they are using code that
may be changed without any notice.
Any thoughts?
I do like the idea in general of being able to mark certain things as
internal to a certain namespace.
My question is more in the direction of: If we are not enforcing
breaking the code but merely emit a warning then that is IMO not
something that we need to implement on the language level. People will
still be able to use the internal method and just ignore the warning.
So when we not break the flow this is something that static analysers
can do as well. They will immediately spot when an internal function is
used outside the expected namespace and can then raise the appropriate
flags so that the problem can be fixed.
That then also raises the question for me whether the attribute actually
needs to be provided by the language itself or whether that is something
that can be added by the static analyzers or - if we want one attribute
for all namespaces - perhaps even by the FIG. THough that would probably
be a case where the FIG would not provide an interface but an actual
class implementation.
Regarding the attribute itself I would declare the namespace it is
supposed to be internal to in the attribute itself.
So something like
namespace MyCompany\PackageA\SubpackageA {
#[Internal(MyCompany\PackageA)] function doStuff(){}
}
might be used to define a function that can be used in all code of
PackageA while still being declared in the Subpackage.
I would like that more than relative "paths" like
namespace MyCompany\PackageA\SubpackageA {
#[Internal(..)] function doStuff(){}
}
or something like that.
Yes, this opens the possibility to even declare functions internal to
packages outside the actual namespace and we might need something to
make sure to disallow that so that the namespace the part is internal to
can only be part of the namespace it is defined in.
My 0.02 €
Cheers
Andreas
Robert Landers
Software Engineer
Utrecht NL
--
,,,
(o o)
+-ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org |
+-+
| https://hei.gl/appointmentwithandreas |
+-+
| GPG-Key: https://hei.gl/keyandreasheiglorg |
+-+
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: [PHP-DEV] Requiring GPG Commit Signing
Hey List, Hey Derick Am 02.04.24 um 16:15 schrieb Derick Rethans: Hi, What do y'all think about requiring GPG signed commits for the php-src repository? In general I think it is a good idea to do GPG signed commits. But in terms of security the idea is to be able to authenticate a user. But the only thing we truly and reliably can do is connect a github account to a commit. Whether that commit author is actually Jane Doe or Karl Napp is still not necessarily proven. So if we want to make sure that something like XY doesn't happen, we have to add some additional restrictions to those GPG keys. If it is just to have signed commits: I am absolutely in favour. Cheers Andreas -- ,,, (o o) +-ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +-+ | https://hei.gl/appointmentwithandreas | +-+ | GPG-Key: https://hei.gl/keyandreasheiglorg | +-+ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] is this thing on?
Hey Folks. Am 05.03.24 um 00:11 schrieb dan...@daniil.it: The VSC part from github (hosting our code), can very easily be ported. Issues, discussions etc can not. With the ongoing enshittification of most of the Internet due to advertising and tracking, we'd be negligent not hosting and owning our own content (including our issue tracker, but that ship has sailed now). PHP actually recently moved from a self-hosted VCS to github due to a hack that compromised php's source code, moving back to a self-hosted instance seems like a downgrade. However, if that's being discussed, it can be done properly, i.e. with a self-hosted gitlab instance, which also provides issues, projects, CI, basically the full devops experience, that would be the perfect chance to also move the mailing list and php wiki to gitlab (which is how many FOSS projects work currently, I.e. wayland, xorg, mesa, pipewire, asahi use the gitlab.freedesktop.org gitlab instance, arch linux has its own gitlab instance (which is also used for RFCs)). Email has been around for half a century. Will things like Slack, Discord, and the like still be operational and allow access to our archives in another 25 years? I'm almost certain it won't be. No one is proposing to move the issue tracker to discord, slack or telegram: those are messengers, and should not be used as support forums for such a major language, mainly because they're non-indexable. Regards, Daniil Gentili If I have learned one thing in decades of software development and emergency management it is: Never change a process in an emergency Processes are there to help in emergencies. They provide stable ways to process information. And in any case, any decission taken in an emergency situation will be influenced by the wish to fastly overcome the emergency and not by the wish to optimize the process. Also discussions about whether a process is necessary or not or needs to be changed wastes resources that can help solve the problem. That said: It is fine to discuss whether the mailinglists are the best thing to foster communication about the development of PHP - when the mailinglist is working fine. When the mailinglist is broken (and it'S not that that happens every other week) the only discussion is either about the development of PHP or how one can help to fix the issue. Some things didn't go well. Some things did go well. We (meaning those that fixed and still fix the issues at hand) might come together for a retrospective once everything works fine again and see what can be improved to help avoid such a situation the next time. Once that is done and everything works fine I am looking forward to an RFC proposing better ways to communicate about all the aspects of developing PHP in a worldwide distributed community of volunteers. Cheers Andreas -- ,,, (o o) +-ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +-+ | https://hei.gl/appointmentwithandreas | +-+ | GPG-Key: https://hei.gl/keyandreasheiglorg | +-+ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] What's up with emails?
On 22 February 2024 17:49:10 CET, Derick Rethans wrote: > On Thu, 22 Feb 2024, mjec wrote: > > > On Thu, 2024-02-22 at 10:29 -05:00, Alain D D Williams > > wrote: > >> On Thu, Feb 22, 2024 at 09:05:22AM -0500, Derick Rethans wrote: > >> > >>> Gmail is rejecting emails after we moved the servers without telling us > >>> why, in enough detail to do anything about it. > >> > >> I run other mail lists and have had similar problems with gmail recently. > > > > Gmail explicitly tightened their requirements for senders this month, so > > while it's likely the server change is related, it may not be the entire > > cause. > > > > Specifically, they require: > > > > - valid spf, with specific rules for quarantining email that has @gmail.com > > From but doesn't pass spf > > - valid dkim > > - dmarc configured if the server sends more than 5k emails to Gmail > > We should have all of that though? > > > > > They also equivocally indicate a requirement for ARC and a List-Id header. > > We have a List-Id header, but I've not even heard of ARC. It is on our list > to investigate though. Our SMTP logs definitely don't say anything about this > though. > > > This is all at https://support.google.com/a/answer/81126. > > > > I think ARC is a must; without it we'll never get to passing dkim at least, > > even if we rewrite from so spf passes. > > But SPF is now passing? The postmaster tools show this: > > Date DKIM success rate SPF success rateDMARC success rate > 15 Feb 2024 100.0% 100.0% 0.0% > 16 Feb 2024 100.0% 100.0% 0.0% > 17 Feb 2024 100.0% 100.0% 0.0% > 18 Feb 2024 100.0% 100.0% 0.0% > 19 Feb 2024 100.0% 100.0% 100.0% > 20 Feb 2024 100.0% 100.0% 100.0% > > > I'm happy to pitch in to help getting this configured if that's helpful, > > though I'm also very conscious that too many cooks is often a greater harm > > than good when it comes to administration. But reach out if you think I can > > be helpful. > > We could definitely use some people that now email delivery. The main issue is that the things came together: Us moving to a new listserver and Gmail introducing new ways of fighting spam. The later is what makes life hars now and would also have caused trouble on the old server. We are currently in the process of implementig all of the stuff that gmail expects us to have. The last ones are ARC and one-click unsubscribe. If you want to know more about the hoops we have to jump in addition to moving the list to a new server check out https://blog.google/products/gmail/gmail-security-authentication-spam-protection/ Cheers Andreas -- Andreas Heigl
Another test-Email
Feel free to disregard. -- ,,, (o o) +-ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +-+ | https://hei.gl/appointmentwithandreas | +-+ | GPG-Key: https://hei.gl/keyandreasheiglorg | +-+ OpenPGP_signature.asc Description: OpenPGP digital signature
Testemail No 4
Disregard this test email. -- ,,, (o o) +-ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +-+ | https://hei.gl/appointmentwithandreas | +-+ | GPG-Key: https://hei.gl/keyandreasheiglorg | +-+ OpenPGP_signature.asc Description: OpenPGP digital signature
Test 3
test 3 -- ,,, (o o) +-ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +-+ | https://hei.gl/appointmentwithandreas | +-+ | GPG-Key: https://hei.gl/keyandreasheiglorg | +-+ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [VOTE] [RFC] Final anonymous classes
Am 03.12.23 um 19:34 schrieb Larry Garfield:
On Sun, Dec 3, 2023, at 10:34 AM, Derick Rethans wrote:
On 3 December 2023 14:49:12 GMT, Nikita Popov wrote:
On Sun, Dec 3, 2023, at 11:40, Daniil Gentili wrote:
Hi all,
I've just opened voting for the final anonymous classes RFC @
https://wiki.php.net/rfc/final_anonymous_classes.
Voting started now, and will run until December 18th 2023, 00:00 GMT.
For the record, I've voted against this proposal because I believe it should
have gone with option 2, that is to *always* make anonymous classes final.
It makes very little sense to me that everyone needs to explicitly mark their anonymous
classes as final just because there is a class_alias loophole that could, in theory, have
been used to extend anonymous classes in the past. Especially given that there is no
evidence of this "feature" being used in the wild (or if there is such
evidence, it was not presented in the proposal).
Regards,
Nikita
I agree with this, and would also say that this RFC is the most thin
one I've seen.
There is no reasoning, or examples, or pretty much anything else in it.
I have also voted no for the same reasons as above. A more fleshed out RFC
that goes default-final (which would then enable the engine optimizations
mentioned) I would probably vote yes for. Though one could debate if that
should be saved for 9.0 just to be safe. (Which I'd also be fine with.)
I also voted NO for the same reason.
But also because I am missing a few things in the RFC.
I am especially missing a reasoning as to why final for anonymous
classes is a thing in the first place. What pain is this RFC adressing?
(Apart from not being able to write `new final class{}`)
Also I'd expect all the relevant information from the discussion to be
in the RFC so that we can figure out what the main points were without
having to dig through Mailinglists or PRs.
Cheers
Andreas
--
,,,
(o o)
+-ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org https://hei.gl/where |
|https://hei.gl/pubkeyandreas |
+-+
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Adding a donate link to the PHP website
Hey Ben On 01.12.23 01:04, Ben Ramsey wrote: On Nov 30, 2023, at 02:45, Andreas Heigl wrote: On 30.11.23 09:39, James Titcumb wrote: On Thu, 30 Nov 2023 at 07:28, Andreas Heigl mailto:andr...@heigl.org>> wrote: [...snip...] I suppose that is actually nothing that an RFC can do as I imagine that everyone from the PHP Group needs to support this and even an RFC wouldn't legally be able to change anything in regards to that. Surely, everyone who has contributed (i.e. has voting karma) has the opportunity to vote, and therefore, if they choose not to vote, that is surely their choice. I don't know the ins and outs of it, but I'd have thought an RFC, well advertised, with plenty of time to ensure as many people can vote who have rights to. What I meant by that is that the members of "The PHP Group" are currently the copyright holders. From a legal point of view no RFC can change that. The only way to change that would be for the PHP Group to transfer their copyright to someone else. What an RFC *can* do though is *propose* that the PHP Group transfers their copyright to the PHP Foundation. Though I'm lo lawyer, so ¯\_(ツ)_/¯ I have spoken at length with a lawyer about this, and the TL;DR version is that every contributor owns the copyright on their specific contributions, if the contributions are copyrightable. Some contributions (typo fixes, white space changes, etc.) aren’t copyrightable, but anything more significant that is the contributor’s own work belongs to them. In other words, even though the license statement says the copyright belongs to The PHP Group[^1] or Zend Technologies Ltd.[^2], technically, these copyrights only apply to the specific code contributed by these organizations or contributed by people for these organizations (through work-for-hire or by legally transferring the copyright to them). Contributing to an open source project is NOT an implicit transfer of your copyright to the project. To do this, every contributor needs to sign a CLA that specifies they are transferring their copyright to The PHP Group. What is implied, however—and I’m told this is how most courts in the US and outside would view it—is assignment of license. When someone contributes to an open source project, they own the copyright on their contributions, but unless they specify a different license that covers their contributions, it’s implied that they are granting use of their contributions under the same license as the project. In this way, the contributor can’t later demand to have their copyrighted code removed; it’s under the terms of the same license, which can't be revoked. Once a copyright statement is placed on a source file, there’s a bunch of legal reasons why you cannot change or remove that copyright statement. In general, you should keep all copyright statements added to a source file and never change one that already exists on a source file. Just look at the file header on any WebKit[^3] source file. WebKit even specifies that you add a copyright notice to each file where you make “significant” changes.[^4] With this in mind, it would be more proper to update the general copyright notice to something like this: Copyright (c) 2023 and later, The PHP Foundation and contributors. All rights reserved. Copyright (c) 1999-2023, The PHP Group and contributors. All rights reserved. Since no reassignment of copyright is taking place, we don’t run into any major legal issues, and this tells a true and accurate story. The PHP Group were stewards of the project until 2023, at which point the community recognized The PHP Foundation as the new stewards of the project, and through all of this time (since 1999), the various copyrights have been owned by their respective owners (i.e., contributors). If you look at the file headers on ICU source code, you can see that Unicode, Inc. made a similar change in 2016.[^5] All this said… I am in favor of making this change. I also have a lot more to say on this, as I’ve been considering opening up an RFC on just this topic. I had intended to reach out to Zend first (through Matthew Weier O’Phinney), but I haven’t done that yet, so this is the first time anyone from Zend has seen these ideas. My apologies. :-) The PHP source code is interesting in that it is covered by two licenses: the PHP License[^6] and the Zend Engine License.[^7] This is an historical artifact of the early days of PHP when it was conceivable that other companies might develop their own engines for PHP, but we know how this story ends: for all intents and purposes, the Zend Engine is PHP and PHP is the Zend Engine. Yes, I’m aware of alternatives (with very limited adoption), and no, they don’t matter for this discussion. Both the PHP License and Zend Engine License are based on the BSD 4-clause “Original” license,[^8] and as a result, neither are compatible with the GPL.[^9][^10] In fact,
Re: [PHP-DEV] Adding a donate link to the PHP website
On 30.11.23 09:39, James Titcumb wrote: On Thu, 30 Nov 2023 at 07:28, Andreas Heigl <mailto:andr...@heigl.org>> wrote: [...snip...] I suppose that is actually nothing that an RFC can do as I imagine that everyone from the PHP Group needs to support this and even an RFC wouldn't legally be able to change anything in regards to that. Surely, everyone who has contributed (i.e. has voting karma) has the opportunity to vote, and therefore, if they choose not to vote, that is surely their choice. I don't know the ins and outs of it, but I'd have thought an RFC, well advertised, with plenty of time to ensure as many people can vote who have rights to. What I meant by that is that the members of "The PHP Group" are currently the copyright holders. From a legal point of view no RFC can change that. The only way to change that would be for the PHP Group to transfer their copyright to someone else. What an RFC *can* do though is *propose* that the PHP Group transfers their copyright to the PHP Foundation. Though I'm lo lawyer, so ¯\_(ツ)_/¯ Cheers Andreas -- ,,, (o o) +-----ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +-+ | https://hei.gl/appointmentwithandreas | +-+ | GPG-Key: https://hei.gl/keyandreasheiglorg | +-+ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Adding a donate link to the PHP website
in any way to make this happen. Cheers Andreas -- ,,, (o o) +---------ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +-+ | https://hei.gl/appointmentwithandreas | +-+ | GPG-Key: https://hei.gl/keyandreasheiglorg | +-+ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Introducing 2 new modes to round function
On 21 July 2023 21:38:03 CEST, Marco Pivetta wrote: > Hey Jorg, > > What is the reason for using this over these? > > * https://www.php.net/manual/en/function.ceil.php > * https://www.php.net/manual/en/function.floor.php > > Hey Marco floor and ceil convert a float to the next int. round can also convert to the next decimal-,level. round(16, -1) will round to 20 whereas round(12, -1) will be 10. And tuere's no way currently to make the first one 10 and the second one 20. Cheers Andreas > > On Fri, 21 Jul 2023, 21:26 Jorg Sowa, wrote: > > > Hello internals! > > > > I would like to propose introducing two new modes to the function > > `round()`: PHP_ROUND_DOWN and PHP_ROUND_UP. > > > > Those modes are highly requested as you can see by the comments on round > > documentation page. First comment mentioning about those modes has 309 > > votes as of today. Introducing those 2 modes would be complementing to the > > rounding in this function. > > > > Round documentation: https://www.php.net/manual/en/function.round.php > > My implementation: https://github.com/php/php-src/pull/11741 > > > > I'm not sure if such minor improvement requires RFC, but as someone may > > have some concerns I create this thread to get your feedback. > > > > Kind regards, > > Jorg > > -- Andreas Heigl -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Interface Default Methods
Hey Michał On 03.07.23 13:32, Michał Marcin Brzuchalski wrote: Hi Levi, pon., 3 lip 2023 o 02:11 Levi Morrison napisał(a): Chatter on the [Interface Default Methods RFC][1] has been quiet for the past 6 days, and the feature freeze deadline is fast approaching for PHP 8.3, so I'm moving this to vote. It'll be open for two weeks as usual. Thanks to everyone who discussed weaknesses in the RFC during the discussion phase. [1]: https://wiki.php.net/rfc/interface-default-methods I voted "yes", my personal use case waits for this feature. My use case example: https://gist.github.com/brzuchal/89e9481bbd34a6ce3d95a68eabff038b I've added two already possible solutions to that as comments. With interface default methods I'd no longer need traits that implement a single or in rare cases 2 methods that use their respective methods returning objects and iterate in Generator fashion over a paginated result set. This is not an issue if there is one implementation of the interface but when I decorate to apply some: * caching * logging * failover That requires that you are in control over both the interface AND the implementation. In which case you probably do not need an interface and the Trait would be enough (using `abstract public function` in traits works after all) So you could even skip the implements part. As the interface should be designed specifically to be implementation-agnostic, adding implementation to the interface is counter-productive. Adding abstract methods to a trait and then just adding the traits is no issue at all especially when you are in control of the interface AND the implementation. When you are NOT in control of the interface... well, you can't expect to have a default implementation and I am already looking forward to the complaints that it is great to have a default implementation, but not *that* one. There is a reason why the respective construct in Rust (which was mentioned in the RFC) is called a Trait and not an Interface. So to decouple the contract from the implementation it is necessary that no implementation is part of the contract. then the trait has to be attached to every class besides that it has to exist which is an additional symbol here. Stop using `implements` at all and solely rely on `use`. My 0.02€ Cheers Andreas -- ,,, (o o) +-ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +-+ | https://hei.gl/appointmentwithandreas | +-+ | GPG-Key: https://hei.gl/keyandreasheiglorg | +-+ OpenPGP_signature Description: OpenPGP digital signature
Re: [PHP-DEV] [VOTE] Interface Default Methods
Am 03.07.23 um 02:11 schrieb Levi Morrison: Chatter on the [Interface Default Methods RFC][1] has been quiet for the past 6 days, and the feature freeze deadline is fast approaching for PHP 8.3, so I'm moving this to vote. It'll be open for two weeks as usual. Thanks to everyone who discussed weaknesses in the RFC during the discussion phase. [1]: https://wiki.php.net/rfc/interface-default-methods I've voted "no" on this RFC for one simple reason: For me an interface is about the abstraction of a contract. It defines how different parts of code interact with one another without having to know about the implementation. With this RFC we are adding implementation details to the abstraction. That requires knowledge about the implementation of different parts of the code. Which we do not have when defining an interface. If we have this knowledge then we are not defining an interface but an implementation were some implementation details need to be overwritten depending on business-logic. That is what an abstract class is there for. And TBH: I do not really care whether there are other languages that think that is a good idea: For me it is not. If one needs default implementations of an interface: Use Traits. But leave the contract abstract. ANd if you need to declare some methods to be implemented while others are fixed: Use abstract classes. My 0.02€ Cheers Andreas -- ,,, (o o) +-ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org https://hei.gl/where | |https://hei.gl/pubkeyandreas | +-+ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC1867 (multipart/form-data) PUT requests
.. you get the picture) One additional function in global namespace and then we can use one of the request-objects that are already out in the wild. I don't think there's a need to invent the wheel again. The advantage might be that no matter how many calls to `request()` you will always get the same result. The Request as it came in. Just my 0.02€ Cheers Andreas -- ,,, (o o) +---------ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +-+ | https://hei.gl/appointmentwithandreas | +-+ | GPG-Key: https://hei.gl/keyandreasheiglorg | +-+ OpenPGP_signature Description: OpenPGP digital signature
Re: [PHP-DEV] RFC [Concept] - Interface Properties
Hey all On 28.05.23 13:52, David Gebler wrote: On Sun, May 28, 2023 at 10:33 AM Rowan Tommins wrote: I don't follow. If a property is public, then code outside the class can rely on being able to access it. That seems to me to be a contract between the class and its users, not an implementation detail - e.g. removing the property, or changing its type, would be a compatibility break. A property can also be inherited from a base class, at which point there is a contract that all descendants of that base class will have the property available. So it seems logical that that contract could also be included in an interface. That's why you can declare constants in an interface (a static final property, to use the lexicon of Java) which we can already do in PHP. At the point you want to bring mutable state into an interface, it's a design smell that what you want, really, is an abstract class or perhaps composition. A couple of languages do allow mutable properties on interfaces, TypeScript being one of them, so yes it's not an unheard of feature - but in TS/JS it's a lot more idiomatic to directly access properties than it is in PHP. I'm not too familiar with C# personally but I have a vague recall that the idea of properties on interfaces there is more akin to the property hooks RFC than Nick's proposal here. And although I'm a little uncomfortable with encouraging getters and setters on interfaces, I'm fully behind property hooks, I hope that RFC passes. PHP already has the sufficient design tools to follow SOLID principles and established design patterns well. If this RFC was in the language tomorrow, you wouldn't be able to do anything you can't already do and do more safely, more robustly, with behavioural interfaces and traits. For me an Interface defines a contract. When the creator of an interface thinks that adding a public (and possibly readonly) property to that contract then I can not really see where the problem is. It allows access to the internal state? Yes. As do getters and setters that can already be declared in an interface. It allows breaking established design patterns? Well... People are very creative in working around what they feel are restrictions. With providing readonly properties we made it possible to not have to declare getters for properties. But that means that accessing those properties can no longer be part of a contract provided by an interface. So IMO we need a solution to that dilemma for interfaces. being able to declare public properties via an interface makes only sense to me then. Just my 0.02€ Cheers Andreas-- ,,, (o o) +-ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +-+ | https://hei.gl/appointmentwithandreas | +-+ | GPG-Key: https://hei.gl/keyandreasheiglorg | +-+ OpenPGP_signature Description: OpenPGP digital signature
Re: [PHP-DEV] Re: [VOTE] PHP Technical Committee
Hey Arvids, Hey all On 12.05.23 17:48, Arvids Godjuks wrote: On Fri, 12 May 2023 at 18:12, Andreas Heigl wrote: Hey Larry, Hey all On 12.05.23 16:42, Larry Garfield wrote: On Fri, May 12, 2023, at 11:57 AM, Jakub Zelenka wrote: On Fri, Apr 28, 2023 at 11:00 AM Jakub Zelenka wrote: Hi, The vote is now open for the RFC about introduction of the PHP Technical Committee: https://wiki.php.net/rfc/php_technical_committee Regards The voting ended with 10 yes votes and 21 no votes. It means that the RFC has been declined. Thanks for voting. Regards Jakub For those who voted no, I would kindly ask: What is your alternative? We have an organizational/structural problem. This isn't really debatable. An eager new contributor was just bullied out of contributing, and the one process we have for dealing with it (RFCs) failed miserably to handle the situation. Ignoring the problem is a bad option. If the TC proposal isn't your preferred way to address it, OK, what is? "Do nothing, it's OK if people occasionally get bullied out of contributing" is not an answer. The internals list has not only recently "failed" miserably. That is not to say that it has been like that since time immemoriable and should therefore stay like that. On the contrary. But we already have a group that has "the say" in PHP. The PHP Group is mentioned in each and every source-file as they are the licence-holder. Instead of adding another group I would rather see that existing group to be filled with new life. Whether that is the right group to tell people in the internals list off is IMO questionable. In essence to me the internals list is a group that discusses technical topics regarding PHPs sources. The outcome and the vote whether something will become part of the code is then voted on in an RFC. That is a rather democratic process. When people are not able to convince the majority of the voters that their idea is a good idea for the PHP sources then it might not be a good idea. Having a group of people with elevated privileges in that process is against that long lived and established current process. And it looks like internals is not yet at that point. Having a group of people that make sure that the tone on the list is civil, on-topic and inviting to newcomers is a different story. But that was not what the vote was about. So for me there already is an elevated group that has a bit more to say regarding the PHP-sources as they are the once "owning" the licence. Adding a second group with elevated privileges regarding code-decissions will not help in keeping the mailinglist civilised and welcoming. On a sidenote: I'd rather try to find a new solution for the PHP Group as licence holder. So the idea of having an elected comitee that coupd perhaps replace the PHP Group was tempting! So my alternative would be for everyone to every now and then reread https://github.com/php/php-src/blob/master/docs/mailinglist-rules.md And as a second step to make internals more welcoming and inclusive might be to have people keep an eye on the tone that can intervene when the debate gets too heated. Those IMO need to be respected people and their influence is in those matters purely on keeping the tone civilized and not have a veto right in regards to code. The internals list and in the end the vote on an RFC should have the last say in regards to code. My 0.02€ Cheers Andreas -- ,,, (o o) +---------ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +-+ | https://hei.gl/appointmentwithandreas | +-+ | GPG-Key: https://hei.gl/keyandreasheiglorg | +-+ Hello Andreas! I think what Larry is asking are ideas on actual solutions, what steps should be made and working out how those recent situations should have been solved/handled. Really it does not matter if will it be PHP Group or some called something else. There has been a lot of discussion off the list in communities among PHP developers and nobody considers the recent events as something that should have happened. The time to "let's throw around some ideas" has passed. The current situation highly reminds me of the year prior to the introduction of the RFC process: this going down a hill at a rapid pace and a lot of people yelling "la la la la" while plugging their ears. The world has cha
Re: [PHP-DEV] Re: [VOTE] PHP Technical Committee
Hey Larry, hey all On 12.05.23 17:36, Larry Garfield wrote: On Fri, May 12, 2023, at 3:12 PM, Andreas Heigl wrote: [...] In essence to me the internals list is a group that discusses technical topics regarding PHPs sources. The outcome and the vote whether something will become part of the code is then voted on in an RFC. That is a rather democratic process. When people are not able to convince the majority of the voters that their idea is a good idea for the PHP sources then it might not be a good idea. Having a group of people with elevated privileges in that process is against that long lived and established current process. And it looks like internals is not yet at that point. Again, not the topic at hand. The TC proposal did not change the feature approval RFC process, at all. It was very explicit about that. It was about non-feature decisions that are highly technical. Those simply do not make sense to apply casual direct democracy to. To take the recent example, there's probably only about 10 people who have any meaningful input to give on "should this include statement be here or over here." The other 990 or so RFC voters, quite honestly, do not have anything meaningful or useful to say, and most probably don't even understand the question. And I include myself in that category. On decisions like that, *please do not ask me, I have nothing useful to contribute*. In other projects I work on these purely technical decissions and discussions are solved using CodeReviews (or Pair/MobProgramming). That doesn't indeed require an RFC. But in the specific case that we seem to try to solve here - at least from what I have seen and read - I doubt that any CodeReview or entity could have made that less messy. So I'm still not convinced that we need a special group of people - apart from the already special group of amazing people that are doing a shitload of great stuff for the language. And the rest is pretty already nicely described in the CONTRIBUTING.md[1] file. For example: > Discuss any significant changes on the list before committing and get confirmation from the release manager for the given branch. or > If you "strongly disagree" about something another person did, don't start fighting publicly - take it up in private email. So in essence we already have the group of people - and they are even elected: The release-managers. So no need to elect another body My 0.02€ Cheers Andreas [1] https://github.com/php/php-src/blob/master/CONTRIBUTING.md#git-commit-rules -- ,,, (o o) +---------ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +-+ | https://hei.gl/appointmentwithandreas | +-+ | GPG-Key: https://hei.gl/keyandreasheiglorg | +-+ OpenPGP_signature Description: OpenPGP digital signature
Re: [PHP-DEV] Re: [VOTE] PHP Technical Committee
Hey Larry, Hey all On 12.05.23 16:42, Larry Garfield wrote: On Fri, May 12, 2023, at 11:57 AM, Jakub Zelenka wrote: On Fri, Apr 28, 2023 at 11:00 AM Jakub Zelenka wrote: Hi, The vote is now open for the RFC about introduction of the PHP Technical Committee: https://wiki.php.net/rfc/php_technical_committee Regards The voting ended with 10 yes votes and 21 no votes. It means that the RFC has been declined. Thanks for voting. Regards Jakub For those who voted no, I would kindly ask: What is your alternative? We have an organizational/structural problem. This isn't really debatable. An eager new contributor was just bullied out of contributing, and the one process we have for dealing with it (RFCs) failed miserably to handle the situation. Ignoring the problem is a bad option. If the TC proposal isn't your preferred way to address it, OK, what is? "Do nothing, it's OK if people occasionally get bullied out of contributing" is not an answer. The internals list has not only recently "failed" miserably. That is not to say that it has been like that since time immemoriable and should therefore stay like that. On the contrary. But we already have a group that has "the say" in PHP. The PHP Group is mentioned in each and every source-file as they are the licence-holder. Instead of adding another group I would rather see that existing group to be filled with new life. Whether that is the right group to tell people in the internals list off is IMO questionable. In essence to me the internals list is a group that discusses technical topics regarding PHPs sources. The outcome and the vote whether something will become part of the code is then voted on in an RFC. That is a rather democratic process. When people are not able to convince the majority of the voters that their idea is a good idea for the PHP sources then it might not be a good idea. Having a group of people with elevated privileges in that process is against that long lived and established current process. And it looks like internals is not yet at that point. Having a group of people that make sure that the tone on the list is civil, on-topic and inviting to newcomers is a different story. But that was not what the vote was about. So for me there already is an elevated group that has a bit more to say regarding the PHP-sources as they are the once "owning" the licence. Adding a second group with elevated privileges regarding code-decissions will not help in keeping the mailinglist civilised and welcoming. On a sidenote: I'd rather try to find a new solution for the PHP Group as licence holder. So the idea of having an elected comitee that coupd perhaps replace the PHP Group was tempting! So my alternative would be for everyone to every now and then reread https://github.com/php/php-src/blob/master/docs/mailinglist-rules.md And as a second step to make internals more welcoming and inclusive might be to have people keep an eye on the tone that can intervene when the debate gets too heated. Those IMO need to be respected people and their influence is in those matters purely on keeping the tone civilized and not have a veto right in regards to code. The internals list and in the end the vote on an RFC should have the last say in regards to code. My 0.02€ Cheers Andreas -- ,,, (o o) +---------ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +-+ | https://hei.gl/appointmentwithandreas | +-+ | GPG-Key: https://hei.gl/keyandreasheiglorg | +-+ OpenPGP_signature Description: OpenPGP digital signature
Re: [PHP-DEV] Re: Improving Mailing-List interactions - was: [PHP-DEV] Moving PHP internals to GitHub
On 13.04.23 10:50, Tim Düsterhus wrote: Hi On 4/13/23 10:46, Andreas Heigl wrote: DMARC is less of a concern, because the list apparently already performs DMARC mangling for a policy that is not 'none' Apart from (possibly) modifying the body and the subject line which then breaks the DKIM signature which then breaks DMARC ;-) I understand how DKIM and DMARC works. For users with a DMARC policy of quarantine or reject the list manager already performs DMARC mangling: The 'From' header is changed from the original 'From' header and instead the list address is put there. Now the DMARC policy of the original sender no longer applies and instead the DMARC policy of the list is used (which does not exist). You can see happening with the email from "Mikhail Galanin via internals" that was sent roughly 10 minute ago. Then we should probably change that so that emails from a domain with DMARC set to 'none' are also not changed. As that just means that DMARC is enabled, the receiving mailserver should just not quarantine or reject the message but instead inform the sender about the problem. With the current settings the sender receives issues and the clients also report that the DKIM signature is invalid. Cheers Andreas -- ,,, (o o) +-ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +-+ | https://hei.gl/appointmentwithandreas | +-+ | GPG-Key: https://hei.gl/keyandreasheiglorg | +-+ OpenPGP_signature Description: OpenPGP digital signature
Re: [PHP-DEV] Re: Improving Mailing-List interactions - was: [PHP-DEV] Moving PHP internals to GitHub
Hey On 13.04.23 10:38, Tim Düsterhus wrote: Hi On 4/13/23 10:29, Andreas Heigl wrote: 1. Remove modification of the emails on the lists server so that DKIM and DMARC will finally work Yes, please, but for different reasons: Filtering is much more reliably performed using the 'list-id' header compared to a Subject prefix and not having the prefix in the Subject makes the INBOX more tidy when also having the [RFC] or [VOTE] prefixes. Also clients apparently can't decide whether to put the 'Re' before or after the prefix. DMARC is less of a concern, because the list apparently already performs DMARC mangling for a policy that is not 'none' Apart from (possibly) modifying the body and the subject line which then breaks the DKIM signature which then breaks DMARC ;-) Cheers Andreas -- ,,, (o o) +-ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +-+ | https://hei.gl/appointmentwithandreas | +-+ | GPG-Key: https://hei.gl/keyandreasheiglorg | +-+ OpenPGP_signature Description: OpenPGP digital signature
[PHP-DEV] Improving Mailing-List interactions - was: [PHP-DEV] Moving PHP internals to GitHub
Hey all On 12.04.23 22:44, Larry Garfield wrote: On Wed, Apr 12, 2023, at 6:42 PM, Rowan Tommins wrote: Which brings me back to my earlier point: I wonder how much of the reaction is really about e-mail itself, and how much is just the documentation and sign-up forms you encounter *before* you hit the list. Because if it's the latter, migrating the entire community to a new platform won't help - we'll still suck at introducing anyone to that platform - and most of what we need is someone who's good with words to update some website copy. I agree, and it's a common pattern, both here and in the earlier thread about deprecations/evolution. Problems exist. Both with the mailing list setup we have, and the evolution/deprecation process. It's not reasonable to deny either. But so often, people lead with "and here's why we should rm -rf and start over" or "and here's why you're all terrible" or other extremely not-helpful "suggestions." That poisons the well, and totally saps any energy for working on the things that can and should be improved incrementally. It makes me very sad, because if someone were actually to volunteer to overhaul the mailing list signup process and verify that it actually, you know, works reliably, there's a good chance they'd be greeted with open arms. (And a fair amount of access skepticism I'm sure, but still, it's no secret that we'd benefit from that.) But that's not what happens. I would like to take this as a first step: As I already do have access to the lists-server I'm happy to work on improving the lists usability. So far I see three different things: 1. Remove modification of the emails on the lists server so that DKIM and DMARC will finally work 2. Improve/Update the interfaces of https://www.php.net/mailing-lists.php 3. Update (or possibly completely remove?) https://www.php.net/unsub.php The latest is linke in the added footer that would be removed by step 1 and that should be unnecessary anyhow as the list-unsubscribe header already should provide the email-clients with a way to show an unsubscribe button right in the email. Any volunteers helping are welcome! And please do voice concerns regarding point 1 Cheers Andreas -- ,,, (o o) +---------ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +-+ | https://hei.gl/appointmentwithandreas | +-+ | GPG-Key: https://hei.gl/keyandreasheiglorg | +-+ OpenPGP_signature Description: OpenPGP digital signature
Re: [PHP-DEV] Moving PHP internals to GitHub
On 12.04.23 16:12, Alex Wells wrote: On Wed, Apr 12, 2023 at 4:57 PM Marco Pivetta wrote: FYI: https://externals.io/message/87501#87501 Also: wow, that was 7 years ago?! :O That was exactly my thought as well... Thanks. I've completely missed this while searching for an alike thread :) But as you mentioned, it's been 7 years. Many things and people have changed. Particularly, PHP has already "vendor locked in" itself into GitHub; and there's now a specific solution from them - GitHub discussions, created specifically to tackle the issues with discussions in GitHub issues. They're not perfect, but hey, neither are mailing lists. The vendor lock-in is one of the biggest issues that I see with the PHP-project. Adding the main discussion platform to the locked resources is probably not one of the best ideas. Just my 0.02€ Cheers Andreas -- ,,, (o o) +-ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +-+ | https://hei.gl/appointmentwithandreas | +-+ | GPG-Key: https://hei.gl/keyandreasheiglorg | +-+ OpenPGP_signature Description: OpenPGP digital signature
Re: [PHP-DEV] Moving PHP internals to GitHub
;DR Cheers Andreas -- ,,, (o o) +-ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +-+ | https://hei.gl/appointmentwithandreas | +-+ | GPG-Key: https://hei.gl/keyandreasheiglorg | +-+ OpenPGP_signature Description: OpenPGP digital signature
Re: [PHP-DEV] 'Uninitialized' creates a lot of cluttering
Hey all. On 13.02.23 13:12, Robert Landers wrote: [...] What is the point of marking the type of a property, other than to prevent mistakes? In non-strict mode, it coerces quite nicely. For example, a string to an integer or an integer to a string. These aren't "mistakes" but making use of the language features. For a type of ?int, null is indeed a valid value; but so is 0, and -1, and so on. Why should the language assume that one default, among all the possibilities, if you don't specify any? I hope we can all agree that `null` is the absence of a value. Now we currently have two different meanings of "absence of a value" which is super annoying sometimes. We have two different "things" that currently return a NULL value. Similar to a function with a void returntype still returning NULL. Perhaps we need to think about introducing "undefined" to make that clearer? But what is actually clearer than throwing an error when trying to access something that is undefined... https://stackoverflow.com/questions/5076944/what-is-the-difference-between-null-and-undefined-in-javascript So how complicated would it be to throw that same error when assigning the return type of a void function to a variable? Cheers Andreas -- ,,, (o o) +---------ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +-+ | https://hei.gl/appointmentwithandreas | +-+ | GPG-Key: https://hei.gl/keyandreasheiglorg | +-+ OpenPGP_signature Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators
Hey All
On 01.02.23 07:20, Mark Baker wrote:
On 23/01/2023 14:06, G. P. B. wrote:
However, the whole point of this RFC is to*remove* cognitive burden for
developers, so they don't even need to be aware of this "feature" and not
get surprised when it kicks in.
Moreover, by your logic, you wouldn't care if we removed support for
alphanumeric strings and only let the PERL increment kick in for purely
alphabetical.
While convenient for you, someone might actually use this feature on
alphanumeric strings, and we're back to "why is my use case being removed
while that other just as weird one remains".
I make no judgement on alphanumeric strings, other than I can't see any
use case for it myself, so I won't allow my objection be considered
hypocritical; and your definition of my use case as "weird" is highly
judgemental.
Bijective numeration using the letters of the alphabet has a long and
ancient tradition, pre-dating our modern numeric Hindu-Arabic system
using base 10 for place/value notation by many centuries. The Abjadi
system used the 28 letters of the Arabic alphabet; similarly the ancient
Greeks and Hebrews, the Armenians; by Russia until the early 18th
Century (each culture using their own alphabet). It's ironic that the
Romans used a very different system, even though our modern western
alphabet is based on the Roman alphabet.
These civilisations didn't consider their alphabetic numeral system
"weird".
How many of the irregularities and idiosyncracies of alphanumeric
strings could be resolved by not trying to cast them as a numeric value
before increment/decrement; but by treating them consistently as
strings? It would resolve the discrepancy with "5d9"; although not with
"0xf9".
The thing that I consider "weird" and that I would really love to see
addressed in a future version of PHP is that the increment of strings
only works with a-z|A-Z while there are a lot of other alphabets where
that should work similar. See https://3v4l.org/k0Nti for such an example.
Incrementing a *string* is something that people should only do when
they know what they are doing. That numeric strings are incremented one
way and other strings another one is indeed something that can irritate
people. And due to the missing type-system in former times it made
sense. But given the by now available type-system using a "sane"
increment could be as easy as `++(int)$var`.
That way it is clear that whatever is in the variable $var should be
treated as integer (or float) and be incremented after the conversion
That way the already existing feature - it is clearly specified in the
documentation and seems to be specified there for the last 20+ years -
would stay the same while still allowing people to easily make sure that
the increment way they expect is used.
Yes! That would mean that `$i = "9"; echo ++$i` would output `A`,
whereas `echo ++(int)$i` would output `10`. But I find that very
intuitive and sane.
Just my 0.02€
Cheers
Andreas
--
,,,
(o o)
+-ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org |
+-+
| https://hei.gl/appointmentwithandreas |
+-+
| GPG-Key: https://hei.gl/keyandreasheiglorg |
+-+
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PHP-DEV] Deprecate ldap_connect with host and port as separate arguments
On 27.01.23 17:28, Christoph M. Becker wrote: On 27.01.2023 at 17:06, Levi Morrison via internals wrote: On Fri, Jan 27, 2023 at 8:54 AM Larry Garfield wrote: On Fri, Jan 27, 2023, at 3:00 AM, Andreas Heigl wrote: I think it would be a good idea to deprecate calling ldap_connect with 2 parameters host and port. This would require an RFC, obviously, but it seems reasonable to me. "Variable meaning parameters" was always a bad idea, and cleaning them up is a good idea.> I disagree that this needs an RFC. The docs have long-said it's deprecated; adding a deprecation message _in code_ to match shouldn't require an RFC. In my opinion, a dedicated RFC would be overkill, but it could be added to the deprecations for PHP 8.3 RFC[1] what doesn't require much effort (feel free to add it, Andreas), Done. Cheers Andreas -- ,,, (o o) +-ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +-+ | https://hei.gl/appointmentwithandreas | +-+ | GPG-Key: https://hei.gl/keyandreasheiglorg | +-+ OpenPGP_signature Description: OpenPGP digital signature
[PHP-DEV] Deprecate ldap_connect with host and port as separate arguments
Hey Folks.
I think it would be a good idea to deprecate calling ldap_connect with 2
parameters host and port.
Wait: What?
Currently there are three ways one can call ldap_connect.
1. With a string $ldap_uri
2. With a string $host and an int $port,
3. With even more parameters for those that did compile PHP with OracleLDAP.
The 3rd way of calling it is not even documented in the docs as it is a
very niche edge-case that would only confuse most people.
The 2nd way of calling the function is based on the since some years
deprecated underlying ldap_open function. Internally we already moved to
the underlying ldap_initialize-function that requires passing an
LDAP-URI. For that we are already converting the passed host and port
into an LDAP-URI of the form 'ldap://$host:$port'.
This already illustrates one of the issues that this way of calling the
function implies: It is not possible to use ldaps as a schema using that
way of calling ldap_connect as it will always use ldap as schema. No
matter which port is passed.
A second reason why I think we should deprecate calling ldap_connect
with two parameters is, that it does not allow one to pass multiple
ldap-servers as it is possible using the LDAP-URI.
This is for sure a BC-break but in my opinion a rather small one as
there are not many users actually using it and there is a clear and easy
migration path for those that use it: Instead of calling
ldap_connect($host, $port)
one calls
ldap_connect("ldap://$host:$port??369;)
Also most of the users should not be affected at all as they are using
3rd party libraries that are already only using an LDAP-URI when calling
ldap_connect like Laminas\Ldap or Symfony\Ldap
The documentation at https://www.php.net/ldap_connect also explicitly
states (for some time by now) that using host and port is considered
deprecated.
Named parameters btw also only support ldap_connect(uri:
'ldap://example.com') and ldap_connect(host:'example.com', port:369)
will throw an error.
There already is a PR open[1] that implements the deprecation so that
for the upcoming PHP8 releases each call to ldap_connect with 2
parameters would emit a deprecation message so that people have enough
time to adapt their code before we can actually remove using two
parameters in the next major release.
Thanks for your comments.
Cheers
Andreas
[1] https://github.com/php/php-src/pull/5177
--
,,,
(o o)
+-ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org |
+-+
| https://hei.gl/appointmentwithandreas |
+-+
| GPG-Key: https://hei.gl/keyandreasheiglorg |
+-+
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] Unicode Text Processing
Hey On 16.12.22 16:21, Tim Düsterhus wrote: Hi On 12/16/22 14:28, Derick Rethans wrote: Question 2 is that class. I know folks have been clammoring for a `String` class for some time and this actually fills that niche quite well. A part of me wonders if we can overload it a little to provide a psuedo locale of "binary" so that users can, optionally, treat it like a more generalized String class in specific cases, storing a normal `char*` zend_string under the hood in that case. Possibly as a specialzation tree. An alternative could be to just have this as an implementation detail, in case the associated locale/collation is C/root. Then nobody needs to worry about it, *but* it would mean implementing everything twice. Which I am not too keen on, especially because we have such a wide array of operations on strings already. I rather not see this either, because if a 'Text' object may contain binary data, the type safety is lost and users cannot rely on "'Text' implies valid UTF-8" (see sibling thread). Does Text contain valid UTF-8? Or valid Unicode? As IIRC the idea was to internally use UTF-16 as encoding. In the end the internal encoding should be irrelevant to the user as long as we can assert that __toString() returns a Unicode-String in a valid encoding. And I'm with you that UTF-8 might be the best choice for that. Cheers Andreas -- ,,, (o o) +-ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +-+ | https://hei.gl/appointmentwithandreas | +-+ | GPG-Key: https://hei.gl/keyandreasheiglorg | +-+ OpenPGP_signature Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] Unicode Text Processing
Hey Derick, Hey all. On 15.12.22 16:34, Derick Rethans wrote: Hi, I have just published an initial draft of the "Unicode Text Processing" RFC, a proposal to have performant unicode text processing always available to PHP users, by introducing a new "Text" class. You can find it at: https://wiki.php.net/rfc/unicode_text_processing I'm looking forwards to hearing your opinions, additions, and suggestions — the RFC specifically asks for these in places. Thanks for tackling this immense topic. I see a few challenges in the approach. My first question was: Why do we need a new implementation of the ICU library? Creating a userland implementation that wraps the currently existing mb-string and ICU functions into a class that allows better usability shouldn't add that much of a performance penalty. And including the mb-string and the intl extension by default wouldn't hurt. That way there would be no added maintenance burden on the core developers. In addition to that it looked to me that there are multiple things mixed up in this Text-class. If we want a Text-class to handle Unicode strings in a better way, why does the string itself need to be Locale-aware? The string itself is a collection of Unicode-Codepoints referencing Characters and Graphemes. Does the string itself need to be aware of a locale to aid in sorting? It needs to be aware of the internal normalization form for character-comparison for sure. But I would rather see a Normalizer handle normalization of the Text-content instead of the Text-class handling that itself. Similarily I'd see the Transliteration done by a separate class. Which then strongly looks similar to the Intl-extension. Which brings me back to the question: Do we really need a second Intl-extension in the core? I'm ambivalent about this. On the one hand it could make some things for sure easier. On the other hand it adds burden onto the core-developers that could be avoided by providing the intl (and mb-string) extension by default instead of having to add them separately. And then find a group if people willing to build a userland implementation. And yes, I know the intl-extension is everything but easy to use. Especially in the quirky edge-cases regarding Transliteration and Normalization. But the issue usually isn't using it but finding the appropriate documentation on the ICU page. Helping the ICU to improve on that documentation would also be a huge benefit. To all those trying to use the Intl-extension right now. But that's just my 0.02€ Cheers Andreas cheers, Derick -- ,,, (o o) +-ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +-+ | https://hei.gl/appointmentwithandreas | +-+ | GPG-Key: https://hei.gl/keyandreasheiglorg | +-+ OpenPGP_signature Description: OpenPGP digital signature
Re: [PHP-DEV] Please allow an out of readonly properties
Hey there On 03.12.22 23:55, Karoly Negyesi wrote: They refuse to compromise even on documentation issues. I am totally helpless. Not sure what could be done? When people design their systems and use final, private or readonly, they have a reason for that. They have a plan on how their library should be used and also how their library should not be used.That is the API that is exposed via public methods that is described in the documentation. When *your* code can only make use of a library by tweaking these constraints, you are using the library in a way that is not intended by the authors. There can be two reasons to that: Either you know exactly what you are doing and you are willing to risk that the way you are using said library might break with every patch version as the internal workings might change. HERE BE DRAGONS: I sometimes actually need to do that (even with a library I wrote myself) but instead of using reflection I then tend to use monkey-patching in that case and actually rewrite the code of the lib on installation. That way the execution is faster as I do not rely on reflection but can access a public property directly. Or - and that is most of the time the case - you are using the library wrong or even using the wrong library. And as you already contacted the authors and they declined your request to change their API, the chances are high, that you are using their Library in an unintended way. In that case you should reconsider what you are doing. Am I using the right library? Why could I be using the library wrongly? How can I change my code to use the provided API of the library? In the end it always boils down to: Check whether your usecase is what the library is intended to solve. And if there is no way around rewriting upstream code: You are on your own! You can not rely upon anything. Not even language features. You are not using upstream code, you are abusing it. My 0.02 € Cheers Andreas On Sat, Dec 3, 2022 at 2:48 PM Marco Pivetta wrote: Talk to the designers then: bringing your own political issues up to the programming language/tooling only makes it worse long-term, for everyone On Sat, 3 Dec 2022, 23:45 Karoly Negyesi, wrote: I do not have the luxury of designing my own system. I am forced to use upstream. I can't help it and given the history of private usage and the refusal on relaxing them I do not see this improving with the readonly. At all. On Sat, Dec 3, 2022 at 2:42 PM Marco Pivetta wrote: Terrible idea: reflection is mostly introspection tooling, and doesn't really bend the rules of the type system, other than crossing scope (it "sees" more). Please consider designing your system to consider the constraints of `readonly` properties, or design the constraints to fit your system instead. Marco Pivetta https://twitter.com/Ocramius https://ocramius.github.io/ On Sat, 3 Dec 2022 at 23:39, Karoly Negyesi wrote: Hello, If push comes to shove, private properties can be changed with reflection. Readonly properties can't. Please add a readonly toggle to reflection. Thanks Karoly Negyesi -- ,,, (o o) +-ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +-+ | https://hei.gl/appointmentwithandreas | +-+ | GPG-Key: https://hei.gl/keyandreasheiglorg | +-+ OpenPGP_signature Description: OpenPGP digital signature
Re: [PHP-DEV] Re: Increase maximum size of an uploaded file to 50Mbyte
Hey all. On 08.09.22 12:35, Jakub Zelenka wrote: On Wed, Sep 7, 2022 at 3:28 PM Christoph M. Becker wrote: On 07.09.2022 at 15:57, Misha wrote: We spend a lot of time to increase limits for uploads file in PHP. Can we increase it in php.ini? Current value is 2Mb. Its so small value, when photo image can take 8Mb on iPhone X. We should increase it to 50Mb, because DevOps engineers do useless work trying to change it. I have prepared PR for it https://github.com/php/php-src/pull/9315 I'm not against increasing the sizes, but 50MB might be too much. Anyway, only changing the php.ini files doesn't make sense in my opinion, since they're probably only used on Windows, and they should reflect the actual default values[1]. It's true that those particular ini files are not directly used on Linux but distros often base their changes on them and the distro provided ones are actually used. So it means that main defaults in main.c are most likely not used. Although I agree they should be changed too so it is consistent. No matter which value we preset, it will most certainly not be adequate. So people *will* have to set it according to their needs. And if they didn't so far, then they are happy with the current setting. Don't get me wrong: I'm not against changing that value. But is it really an issue that needs solving? It's a default value of a configuration file. When I'm unhappy with the default, I change it to a more suitable value. When I'm not able to do that... perhaps I should leave my fingers not only from the config file... My 0.02€ Cheers Andreas -- ,,, (o o) +-ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +-+ | https://hei.gl/appointmentwithandreas | +-+ OpenPGP_0xA8D5437ECE724FE5.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] Asymmetric visibility
Hey Marco.
On 08.08.22 10:14, Marco Pivetta wrote:
Heyo Andreas, Casper,
On Mon, 8 Aug 2022 at 10:03, Andreas Heigl wrote:
Hey Casper.
On 08.08.22 09:54, Casper Langemeijer wrote:
Hi all,
In the discussion I sometimes see the terminology 'readonly' and
'writable' being used. This is confusing because when the property is an
object that itself is mutable, there is nothing read-only about it.
The terminology in the RFC seems right to me, and overall it seems solid.
However, I'm not convinced this RFC is solving a real issue. I could not
find any reasoning in the RFC, except that Swift has a very similar
language feature.
To me it solves the topic of making a property readable but not
writeable from the public while still allowing it to be written to
within the private or protected context.
So enforcing usage of a public setter-metbhod but not having to use a
getter.
Soemthing like this
final class Foo
{
public private(set) string $username;
public function changeUsernameTo(string $newUsername): self
{
if (! newUsernameIsUnique($newUsername) {
throw new RuntimeException('The username is not unique');
}
$this->username = $newUsername;
return $this;
}
}
readonly only solves that for immutable properties but there currently
is no way of solving that for mutable properties.
Similar question as Casper here: I use `readonly` properties aggressively,
and I try to make the state as immutable as possible.
In the **extremely** rare cases where `public get` and `private set` are
needed, I rely on traditional getters and setters, which are becoming
extremely situational anyway, and still work perfectly fine.
If that doesn't work, then PHPStan/Psalm allow declaring `@private`,
`@internal`, `@phpstan-internal` or similar mechanisms to restrict scope
access. `qossmic/deptrac` also works wonders here, compared to PHP. >
In fact, I'm writing so few getters and setters these days, that I don't
see why I'd need getter and setter semantics to creep into the language,
especially mutable ones, not even with the reflection improvements.
Your use case might not need them (though actually you are needing them,
you just don't use them as language feature but via the static-analysis
annotation)
But when discussing language features we should always keep ALL users of
the language in mind. And if a feature helps in providing ways to build
more stable code on the language level then we should think about that
from a point of view of *all* users.
And when the feature is already used via static-analysis then why not
implement that for use by *everyone* and not only those that have static
analysis in their CI toolchain.
Just my 0.02€
Cheers
Andreas
--
,,,
(o o)
+-ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org |
+-+
| https://hei.gl/appointmentwithandreas |
+-+
OpenPGP_0xA8D5437ECE724FE5.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] Asymmetric visibility
Hey Casper.
On 08.08.22 09:54, Casper Langemeijer wrote:
Hi all,
In the discussion I sometimes see the terminology 'readonly' and 'writable'
being used. This is confusing because when the property is an object that
itself is mutable, there is nothing read-only about it.
The terminology in the RFC seems right to me, and overall it seems solid.
However, I'm not convinced this RFC is solving a real issue. I could not find
any reasoning in the RFC, except that Swift has a very similar language feature.
To me it solves the topic of making a property readable but not
writeable from the public while still allowing it to be written to
within the private or protected context.
So enforcing usage of a public setter-metbhod but not having to use a
getter.
Soemthing like this
final class Foo
{
public private(set) string $username;
public function changeUsernameTo(string $newUsername): self
{
if (! newUsernameIsUnique($newUsername) {
throw new RuntimeException('The username is not unique');
}
$this->username = $newUsername;
return $this;
}
}
readonly only solves that for immutable properties but there currently
is no way of solving that for mutable properties.
Just my 0.02€
Cheers
Andreas
--
,,,
(o o)
+-ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org |
+-+
| https://hei.gl/appointmentwithandreas |
+-+
OpenPGP_0xA8D5437ECE724FE5.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] Asymmetric visibility
Hey Larry, hey all
On 07.08.22 21:01, Larry Garfield wrote:
On Sun, Aug 7, 2022, at 5:54 AM, Lynn wrote:
On Sun, Aug 7, 2022 at 12:34 PM Rowan Tommins
wrote:
Can you expand on where you think the ambiguity / implicitness is? As I
understand it, the RFC is proposing exactly three new combined access
levels:
- "public private(set)"
- "public protected(set)"
- "protected private(set)"
Although aesthetically it will take a bit of getting used to, it seems to
me pretty clear that the first means "mostly public, but private if you
want to set it", and so on.
The only thing I can think of that could be described as "implicit" is
that accessing a property by reference is considered a "set" operation,
which I'm not sure how any implementation could avoid.
Personally for me it's the syntax. Reading "public private", "public
protected", or "protected private" reads really weird `public private(set)
static self $property`. In the end it makes sense if you know what it
means, otherwise it's probably confusing. I really like this RFC and I feel
like this might just be the way to go forward, but I have my doubts about
how many more keywords can be realistically added before it becomes a
problem.
What syntax would avoid having the visibility keyword repeated? if you want "public get, private
set" behavior, I don't know how that could be done without having the words "public" and
"private" both appear somewhere.
Also note, since using private(set) is mutually exclusive with readonly, that the
resulting keyword list is about the same length as the existing "public readonly
string $foo" that has cropped up frequently with PHP 8.1. So... yes it's another
keyword, but it's not more keywords that can exist simultaneously. And moving the
keyword to the right (a la C#) wouldn't make it any shorter; if anything it would be even
more keystrokes.
Very close in size, same in complexity:
public readonly string $foo
public private(set) string $foo
In my opinion those are actually two different things.
One is allowing a variable to be publicly readably and writeable. But it
can only be set once. Every subsequent call to setting a new value will
fail.
The other is allowing different scopes for reading and writing the
variable. The variable can be read publicly but can only be set from
within the current class-context. But setting it from the current class
context can happen multiple times.
So it should indeed be possible to combine both possibilities:
public(get) private(set) readonly string $foo;
My 0.02€
Cheers
Andreas
--
,,,
(o o)
+-ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org |
+-+
| https://hei.gl/appointmentwithandreas |
+-+
OpenPGP_0xA8D5437ECE724FE5.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] Add json_encode indent parameter
On 05.07.22 11:38, Jakub Zelenka wrote: On Tue, Jul 5, 2022 at 8:37 AM Andreas Heigl wrote: Hey all. On 05.07.22 02:04, Peter Cowburn wrote: On Mon, 4 Jul 2022 at 11:11, Jakub Zelenka wrote: On Mon, Jul 4, 2022 at 8:38 AM Timon de Groot wrote: Hi internals, If the rest also thinks the RFC is good to go, I suggest we start a vote coming week. As this is my first RFC, I'm not so sure how this typically gets kicked off, so I'd like to know what I need to do! You just need to change status in RFC to Voting and in voting section set the date range and add doodle poll - you can basically copy it from one of the open RFC's (see for example code in https://wiki.php.net/rfc/fetch_property_in_const_expressions ). Then you just need to send email to internals with subject prefixed with [RFC][VOTE] or similar. As noted you need to do it today or latest tomorrow. Feel free to let me know if you are too busy or something is not clear. I would recommend not to do any last time changes as in such case you should probably give an extra time for dicusion which means it won't make the feature freeze and will have to wait for another year. In my opinion it is good as it is. The tabs can be later added as an extra flag. If the flag is set, we could just change default value for indent to 1 and use tabs but it would be still possible for users to set indent size if they wish. I think that's something that makes most sense to me and doesn't impact the current RFC in any way. Regards Jakub My thoughts might be firmly in the realms of "too little, too late" since the vote is open already, so by all means choose to ignore. I'll be on the same lines! What I would have prefered is instead of a the new parameter $indent having a numerical value to have a string value. That would have allowed the following: json_encode($data, indent: ""); or json_encode($data, indent: "\t"); That would have made the tabs vs. spaces very easy and people can also add whatever they want to set for one indentation. Think about setting dots for making the spaces visible for some formatted output or whatever else people might think of. The problem with this approach is that we either need to validate it (which is probably not a big deal but you still have just option or using spaces or tabs) or we allow invalid JSON to be produced from this function which I think it's not a good idea and should not be part of json_encode because, as its name suggests, that function is just for encoding JSON and not some random format. My guess is that it would be even less likely to pass and I would certainly vote against it. I think if this RFC fails, we could maybe allow number or validated string and also do that auto setting of flag if set as suggested. Then perhaps adding a separate function "json_format" would be the better approach? Keep `json_encode` to *only* encode json into a "binary" format (and then it's irrelevant whether that's spaces or tabs) and explicitly use a different function to handle possible formatting topics with different spaces, tabs whatever-else-one-might-find-adequate Cheers Andreas -- ,,, (o o) +---------ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +-+ | https://hei.gl/appointmentwithandreas | +-+ OpenPGP_0xA8D5437ECE724FE5.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] Add json_encode indent parameter
Hey all. On 05.07.22 02:04, Peter Cowburn wrote: On Mon, 4 Jul 2022 at 11:11, Jakub Zelenka wrote: On Mon, Jul 4, 2022 at 8:38 AM Timon de Groot wrote: Hi internals, If the rest also thinks the RFC is good to go, I suggest we start a vote coming week. As this is my first RFC, I'm not so sure how this typically gets kicked off, so I'd like to know what I need to do! You just need to change status in RFC to Voting and in voting section set the date range and add doodle poll - you can basically copy it from one of the open RFC's (see for example code in https://wiki.php.net/rfc/fetch_property_in_const_expressions ). Then you just need to send email to internals with subject prefixed with [RFC][VOTE] or similar. As noted you need to do it today or latest tomorrow. Feel free to let me know if you are too busy or something is not clear. I would recommend not to do any last time changes as in such case you should probably give an extra time for dicusion which means it won't make the feature freeze and will have to wait for another year. In my opinion it is good as it is. The tabs can be later added as an extra flag. If the flag is set, we could just change default value for indent to 1 and use tabs but it would be still possible for users to set indent size if they wish. I think that's something that makes most sense to me and doesn't impact the current RFC in any way. Regards Jakub My thoughts might be firmly in the realms of "too little, too late" since the vote is open already, so by all means choose to ignore. I'll be on the same lines! What I would have prefered is instead of a the new parameter $indent having a numerical value to have a string value. That would have allowed the following: json_encode($data, indent: ""); or json_encode($data, indent: "\t"); That would have made the tabs vs. spaces very easy and people can also add whatever they want to set for one indentation. Think about setting dots for making the spaces visible for some formatted output or whatever else people might think of. And setting the "indent" parameter would always implicitly set the flag "JSON_PRETTY_PRINT" (as it doesn't make sense to not have that set). The current way of just being able to set a number of spaces to indent or to use a flag for tabs is a bit fiddly at best and does make adding accessibility a second class citizen. Therefore I will vote against this current implementation. Cheers Andreas -- ,,, (o o) +---------ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +-+ | https://hei.gl/appointmentwithandreas | +-+ OpenPGP_0xA8D5437ECE724FE5.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC][Under discussion] Create a global login system for php.net
Hey All. On 28.05.22 11:53, Aaron Junker wrote: Hi all, I would like to start the discussion on my RFC for creating a global login system on php.net: https://wiki.php.net/rfc/global_login. When you have feedback to a specific point of the RFC, please use the corresponding number used in the RFC. I do have my issues with the general RFC. The idea to have one login system to all parts of the PHP internals ecosystem seems tempting for sure. But as you pointed out in the introduction, there are 9 different services - partly rather old ones - that would require some work to make SSO work. Some of them we have control over, some of them we do not (as those are external applications that we are using. Fiddling with their sourcecode might be possible but will leave us more or less unable to update the tools) So moving those applications that we have control over towards SSO will bind resources. And not only now, but also in the future as those tools might need updates as well. Resources though, espechialy for infrastructure, are a very rare good! In addition I would say that we can assume the edit.php.net to be dead after we moved documentation from SVN to git. So that is awesome as that means "one down" and we couldn't already find someone to modify edit.php.net to work with git instead of SVN. So that's great news! But the bad news is, that there is also the colobus system which powers the NNTP-server backend that a number of people use to interact with the mailing-list. Which also has an authentication and would therefore need to be switched. So we are back at 9 services. And we switched one that is completely under our control to one that isn't as we are merely using a (rather old by now) service. And there might even be more than those. So what I'm trying to bring across here is that this task will bind a lot of resources with a gain that I'm not sure is worth the effort. And instead of binding people working on resources that improve the life of a few (those working on these quirky systems) I'd rather see those resources spent where they improve the life of all PHP-Developers. Like improving the docs, triaging bugs, answering questions on StackOverflow/Room11/PHPC/Whatever else there is. In addition to that I would like to raise my concerns over using GitHub login for everything (Topic 1.2). GitHub is a company based in the US and therefore bound to US law. That already means that people from certain countries can not (easily) collaborate and are therefore also excluded from contributing in any way to PHP[1]. In addition to those regulations directly by GitHub some countries are blocking access to GitHub on their own account which means that Developers from Russia or China will have a harder time contributing to PHP due to the fact that they are not able to login into any system. Are we aware of that? On the other hand maintaining our own SSO-Solution will bind even more resources... See above. In addition: The number of different logins is usually rather small per person. And keeping track of the different systems and passwords via a PasswordManager should solve most of the day-to-day hassle. Having a central place though to document the hassle would be a very helpful addition to the PHP ecosystem! My 0.02€ Cheers Andreas - The one having struggled for some years with just *one* infra-change. [1] https://docs.github.com/en/site-policy/other-site-policies/github-and-trade-controls#on-which-countries-and-territories-are-us-government-sanctions-applied Best regards Aaron Junker -- ,,, (o o) +-ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +-+ | https://hei.gl/appointmentwithandreas | +-+ OpenPGP_0xA8D5437ECE724FE5.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC][Under discussion] Arbitrary string interpolation
Hey Ilija.
On 25.03.22 15:38, Arnaud Le Blanc wrote:
Hi Ilija
I find that sprintf() is easier to read in most cases. One reason for this is
that the text is separated from the code. It's also easier to review for
humans and linters.
The strtoupper example would look like this with sprintf:
$world = 'world';
echo sprintf('Hello %s!', strtoupper($world));
Longer examples can be nicely split in multiple lines:
echo sprintf(
'Received HTTP status code %d (reason phrase: %s)',
$response->getStatusCode(),
$response->getReasonPhrase(),
);
This technique also allows me to use the original string in translation
while still keeping the replacements out of that.
So something like
echo sprintf(
gettext('Hello %s!'),
strtoupper($world)
);
would easily work and provide the translator only with the string `Hello
%s` which is much less to break than `Hello {strtoupper($world)}!`
So for internationalized applications I'd rather keep the sprintf
approach than a new string-syntax.
A way to use sprintf in a more out-of-the-box way like in ruby would be
awesome! Something like
echo 'Hello %s' % [strtoupper($world)];
or
echo 'Hello %{world}' % ['world' => strtoupper($world)];
But I'm absolutely happy with the current sprintf functionality.
Just my 0.02€
Cheers
Andreas
--
,,,
(o o)
+-ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org |
+-+
| https://hei.gl/appointmentwithandreas |
+-+
OpenPGP_0xA8D5437ECE724FE5.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC][Under discussion] Deprecate ${} string interpolation
Hey Ilija. On 11.03.22 18:13, Ilija Tovilo wrote: Hi everyone It's been a while. Hope you are doing well. Last year I sent an e-mail to the mailing about the current state of string interpolation in PHP. I have now created an RFC to better explain the current behavior and why it would make sense to deprecate/remove some of it. https://wiki.php.net/rfc/deprecate_dollar_brace_string_interpolation Previous thread: https://externals.io/message/111519 Let me know what you think. As I already stated on twitter[1] for me there are multiple things missing: First of all it would make it much easier for me to see what impact this RFC has if there were any numbers in it of how many large-scale repositories on for example github are affected by this. But on the other hand, and that's much more important to me, I am missing the part where you explain the concrete benefits of that deprecation for the evolution of the language. In evolution everything is fine as it is unless it directly hinders the forthcoming and development of new essential features. IN PHP that means - at least for me - as long as something is not in the way of a new feature or a strategy we leave it as it is. Deprecating something in terms of raising a deprecation message in the error log, means that something is going to go away in one of the next versions. We are going to remove a feature because we have a strategy to improve something in that part. Be it complexity in the source code or replacing a functionality or speeding up the language. But so far I can see none of these things to apply here. The only argument that you are giving in the RFC are that they are "rarely useful" (reminds me a bit of Jack Sparrows "Ah! But you have heard of me") and that they are easily confused. While the later argument would also speak for unifying the needle/haystack parameter order it is also making an assumption. Which is not backed by any statistics. How many bug reports do we have in the bug tracker due to this "confusion"? Also what is "useful" is always a rather subjective matter. Just because I don't find feature X useful doesn't mean that others can't find it useful. But what worries me the most is that your proposal to deprecate and essentially remove some string features that have been in the language for quite some time and have once been considered relevant is not giving me an idea of how that will benefit the language itself. How that will immediately allow us to improve the language. By either removing 20% of code that we suddenly don't need to maintain any more or because it will allow us to immediately implement feature X in PHP9. And just removing something to allow a different RFC that "might" allow proposing other stuff is premature optimization. We might be able to need this feature, so let's tweak our code for that possibility right now. Without knowing whether that might actually be happening. And we should not remove features *now* just because someone at one point in a future might want to do something. So while I appreciate the idea of a cleaner API I will for sure vote "no" on this RFC in it's current form. My 0.02€ Cheers Andreas [1] https://twitter.com/heiglandreas/status/1502338172210065409 -- ,,, (o o) +---------ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +-+ | https://hei.gl/appointmentwithandreas | +-+ OpenPGP_0xA8D5437ECE724FE5.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [PHP-DEV] PHP Community to support Ukraine and help to stop Russian agression
Hey Paul, All. On 03.03.22 00:45, Paul Dragoonis wrote: On Wed, Mar 2, 2022 at 11:11 PM Paul Crovella wrote: On Wed, Mar 2, 2022 at 1:08 PM Stanislav Malyshev wrote: That said, if somebody were to design a logo version with Ukraine flag In case anyone has use for it: https://svgshare.com/i/epJ.svg Colors are #0057b7 and #ffd700, from https://en.wikipedia.org/wiki/Flag_of_Ukraine#Design, with a white stroke. Opinions aside: PHP, like many other OSS projects, has substantial amounts of people in Russia and non-Russia. Fact. Let's keep an OSS project focusing on the technology that we're building here, and take politics out of the equation here, entirely. Please can we go to the correct platforms such as Twitter, FB, LinkedIn, and others, for such conversations, discussions, moralities, and debates? We all love the PHP project, and let's not get it dragged into the mess going on in the outside world. OSS for many is a safe haven to sink your work and focus into, stress relief, an outlet, and a place free from outside world problems; let's try to healthily keep it that way, shall we? OSS might not be the safe haven for everyone as some might have not on their radar. Think of the prominent cases of Stallman and Thorvals. OSS can only be a safe haven when we take action to make sure that they are actually safe. And one of these actions can be to make it very clear that violence, aggression, intolerance and fake news have no place in this community. Not by saying so or being tolerant about them, but by explicitly showing that we want to be a safe haven. And yes: Substantial parts of PHPs code are from Russian as well as from Ukranian developers. And some of the later ones currently are not able to contribute because they are right now, at this very moment, trying to defend their homes, their families and their lives against an illegal invasion from a foreign government. So the PHP project has already been dragged into this mess. It is not a project outside of space and time. We all are the PHP project. And some of us are being forced to fear for their lives due to some dick wanting to show off. Cheers Andreas -- ,,, (o o) +-ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +-+ | https://hei.gl/appointmentwithandreas | +-+ OpenPGP_0xA8D5437ECE724FE5.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [PHP-DEV] PHP Community to support Ukraine and help to stop Russian agression
Hey. On 02.03.22 14:56, naitsi...@e.mail.de wrote: Am 02-Mar-2022 13:51:07 +0100 schrieb ocram...@gmail.com: Hey Christian, On Wed, Mar 2, 2022 at 1:41 PM wrote: this is exactly the problem. Russia did not just invaded Ukrainia out of nowhere. The story started in 2014 with the illegal coup d'etat against Viktor Yanukovych and its acceptance by the western countries. Or even earlier, with the eastern extension of the EU and the Nato, to get Ukriane on their side, stoping the political neutrality of Ukraine between Russia and the western. As you see, it is not as simple. Should we start a discussion now? I do not think so. It would not help anybody. Wars or conflicts are never simple. Usually there's a long story. Taking ones side in political conflicts will separate the community for sure. Please do not start that. You and anybody else can show their political position on twitter, facebook or elsewhere. We do not need to do that on php.net. Please GTFO: we don't need more of Putin's propaganda over here, as they're busy enough with butchering civilians over there. Greets, Marco Pivetta Hi Marco, this is exactly what I meant. It leads to separation of the community and hate against each other. You judge my statement as Putin propaganda although I have not said I am supporting Putin or the war. I only wanted to make clear, that if we start to support Ukraine as the victimized party in this conflict we have to do that in other conflicts, too. Look at the Iraquis who were attacked by the USA, the Uyghurs in China, the poulation in Noth Korea or the war in Yemen. Thousands of people are dying there every year and nobody is raising his voice. The US attack against Iraq was ... debateable but is by now history. Yes: We perhaps should have taken a side at that time! We can learn from that! The other things you mention are state-internal affairs that are far from being OK! Don't get me wrong on that! But they do not qualify as invading a separate country! As an act of war. They are internal affairs and as such sadly qualify differently. And despite us having ideas about human rights etc taking sides in an internal affair always has a connotation of Colonialism. "We know it better". But in the case of Ukraine there is a clear aggressor that has invaded an independent country which is against all internationally agreed upon laws, rules and regulations. Not standing up against that silently tolerates that behaviour. Which is not something I like to endorse. And standing up against the injustice against the Ukraine does not negate the other injustices around the world. Whether that is the way women are being treated by the new Afghanistan government, the uigurs in China are treated, the whole mess in and around Israel or the way POC are treated in the US. And this totally incomplete list is in no way trying to compare these different things with one another. Maybe I can give you an example to make clear what I mean: If the banner for the Ukraine is shown on php.net. I could request a banner for the people in Hong Kong who are suppressed by China, too. If you refuse it, it would be very unfair. If you say "yes" there should come more requests. Then php internals will have to create rules when php.net should show its solidarity and when not. The rule would be: Internal affairs are shit but they are exactly that: Internal affairs. A war of aggression (one country attacking another one without the justification of self-defence) IMO justifies solidarity with the attacked country. Cheers Andreas -- ,,, (o o) +-ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +-+ | https://hei.gl/appointmentwithandreas | +-+ OpenPGP_0xA8D5437ECE724FE5.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [PHP-DEV] PHP Community to support Ukraine and help to stop Russian agression
Hey Aaron. On 02.03.22 14:34, Aaron Junker wrote: Hi all As I see this there is strong agreement against war, but not for taking a side on a conflict. So then why not showing a banner or something against war. No war or side in particular just for humanity and peace. I think that's something everyone could agree with. Let me know what you all think. As previous posts here have show: there are strong proponents of the idea. So to move forward with this I'd recommend to create a PR against the website-repo on github and we'll discuss the concrete implementation there and eventually merge and deploy it. Provide a Screenshot of what it will look like and I'm sure we will have a fruitful discussion there. Cheers Andreas -- ,,, (o o) +-ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +-+ | https://hei.gl/appointmentwithandreas | +-+ OpenPGP_0xA8D5437ECE724FE5.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [PHP-DEV] PHP Community to support Ukraine and help to stop Russian agression
Hey All On 02.03.22 13:50, Marco Pivetta wrote: Hey Christian, On Wed, Mar 2, 2022 at 1:41 PM wrote: this is exactly the problem. Russia did not just invaded Ukrainia out of nowhere. The story started in 2014 with the illegal coup d'etat against Viktor Yanukovych and its acceptance by the western countries. Or even earlier, with the eastern extension of the EU and the Nato, to get Ukriane on their side, stoping the political neutrality of Ukraine between Russia and the western. As you see, it is not as simple. Should we start a discussion now? I do not think so. It would not help anybody. Wars or conflicts are never simple. Usually there's a long story. Taking ones side in political conflicts will separate the community for sure. Please do not start that. You and anybody else can show their political position on twitter, facebook or elsewhere. We do not need to do that on php.net. Please GTFO: we don't need more of Putin's propaganda over here, as they're busy enough with butchering civilians over there. Thanks Marco! Standing up against bullies is something that this community so far has been great at. Taking no side in a political conflict means taking the side of the bully. And THAT will separate the community! And taking the side of Ukraine does not make other conflicts less valid or cruel. It's standing up against injustice. Cheers Andreas -- ,,, (o o) +-ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +-+ | https://hei.gl/appointmentwithandreas | +-+ OpenPGP_0xA8D5437ECE724FE5.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [PHP-DEV] PHP Community to support Ukraine and help to stop Russian agression
Hey All On 02.03.22 11:16, Aaron Junker wrote: I'm not an internal, but I support this idea. From: Lynn Sent: Wednesday, March 2, 2022 10:36:32 AM To: Victor Bolshov Cc: PHP internals Subject: Re: [PHP-DEV] PHP Community to support Ukraine and help to stop Russian agression On Wed, Mar 2, 2022 at 10:31 AM Victor Bolshov wrote: Hello internals. In these dark days for humanity, we as people of civilization, people of sanity, kind and caring people with children and families - we have to speak up, loud and clear, in support for Ukraine. To stop Russian aggression. I suggest to add Ukranian flag and a supportive anti-war disclaimer to the header of php.net website. Why is this important? There are a lot of PHP developers in Russia. A lot of them, sadly, have been brainwashed by Putin's propaganda. They still must have a lot of respect to PHP authors and creators. Seeing that these people, who have their respect, are against the war and for the freedom of Ukraine, might have an impact. This is not the time to "stay away from politics", we are experiencing an attack on humanity itself. Take example from <https://junit.org/junit5/> and their clear statement. Say NO to war! +100, Symfony has also added a banner on the front page that links to https://symfony.com/blog/symfony-stands-with-ukraine I'd be in favour of the idea as well. Best would be though to create a PR against the https://github.com/php/web-php repo. Cheers Andreas -- ,,, (o o) +-ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +-+ | https://hei.gl/appointmentwithandreas | +-+ OpenPGP_0xA8D5437ECE724FE5.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [PHP-DEV] [VOTE] User Defined Operator Overloads
Hey Jordan. On 05.01.22 10:42, Jordan LeDoux wrote: On Tue, Jan 4, 2022 at 10:50 PM Pierre Joye wrote: I hesitated too, however I think we can't escape this feature. Like it was for the annotation, we need to find a compromise. Your points are valid so I wonder if the RFC could be modified and get to the point we could reach that compromise. There will be the oppositions for the features as a whole, however I am optimistic about our abilities to get there this time rather than wait yet again a few years for something we know we will have anyway. I will certainly be making changes before bringing this RFC back if it is rejected. What exactly those changes are I am not certain yet, but the feedback I receive here from voters will obviously have a large impact on that. As i mentioned elsewhere, swapping to a magic method syntax would be about 2-3 hours of work, I could do that very quickly. But I don't want to make a change like that after the voting has started, so any such changes will have to wait. I suppose the alternative would be to withdraw the RFC now that a wider variety of voters are providing feedback than the other three threads. I'd rather not see more magic being introduced. That would for me be a reason to vote against the RFC. No matter what it does. Just my 0.02 € Cheers Andreas -- ,,, (o o) +-ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +-+ | https://hei.gl/appointmentwithandreas | +-+ OpenPGP_0xA8D5437ECE724FE5.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [PHP-DEV] What should we do with utf8_encode and utf8_decode?
Hey All. On 22.12.21 10:08, Andreas Heigl wrote: Hey all. On 22.12.21 10:00, Rowan Tommins wrote: [...] On 22/12/2021 00:31, Kris Craig wrote: Now might be a good time to make this into an RFC. :) I have a draft kicking around with a lot of analysis of current usage. I will try to pick it back up after Christmas. I just dug a bit deeper on the subject and found this RFC from 2016: https://wiki.php.net/rfc/remove_utf_8_decode_encode Perhaps we can just revive that one! Cheers Andreas -- ,,, (o o) +-ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +-+ | https://hei.gl/appointmentwithandreas | +-+ OpenPGP_0xA8D5437ECE724FE5.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [PHP-DEV] What should we do with utf8_encode and utf8_decode?
Hey all. On 22.12.21 10:00, Rowan Tommins wrote: On 21/12/2021 23:20, Wade Rossmann wrote: I would suggest adding optional source/destination encoding parameters to the functions, eg: utf8_encode(string $string, string $source_encoding = "ISO-8859-1") utf8_decode(string $string, string $destination_encoding = "ISO-8859-1") That's an interesting idea, and definitely worth considering. In the much longer term, we could make the parameter mandatory rather than deprecating the entire function. As you say, the challenge is how to implement the other encodings / what to do if ext/mbstring is not installed. It would be very tempting to support Windows-1252 directly, because it's just a few characters on top of the existing mappings, and is so commonly mistaken for ISO-8859-1. Anything else could then perhaps give a run-time error if ext/mbstring wasn't found. > On 22/12/2021 00:31, Kris Craig wrote: Now might be a good time to make this into an RFC. :) I have a draft kicking around with a lot of analysis of current usage. I will try to pick it back up after Christmas. Regards, To be quite honest: Despite the huge outcry that might provoke: I'd rather remove them today than keep them or deprecate them. And I'd declare the removal as a bug-fix! Due to the way those functions are currently working they have caused more harm than actually good. One had to very explicitly know what they are doing to use them in the right way. And most certainly when they worked as expected that was more likely due to sheer luck than because someone knew what they were doing. So giving those functions a continued lifetime either as an alias to mb_convert_encoding or by implementing the conversion to/from Windows-1252 would still leave people under the impression that it is a magic function. I'd rather prefer to get rid of them and point people to the proper way of converting one character set to another one with all the possible mishaps that will occur. Just my 0.02€ Cheers Andreas -- ,,, (o o) +-----ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +-+ | https://hei.gl/appointmentwithandreas | +-+ OpenPGP_0xA8D5437ECE724FE5.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [PHP-DEV] Re: [RFC] Deprecate dynamic properties
Hey list. On 16.11.21 16:26, Deleu wrote: On Tue, Nov 16, 2021 at 3:59 PM James Gilliland wrote: On Tue, Nov 16, 2021 at 4:23 AM Rowan Tommins wrote: On 16/11/2021 09:27, Andreas Heigl wrote: I see, yes, code that is 100% perfectly tested can get away without the language performing any error checking at all - the behaviour is all guaranteed by the tests. I would be very surprised if even 1% of PHP applications can claim such comprehensive tests. The topic here was that new code can verify the declaration of a property by using tests. That does not need to happen on the language level. I was never talking about adding tests for existing code. For most code bases, even new ones being written from scratch in PHP 8.0, that level of testing simply doesn't exist, and having the language tell you "hey, you wrote $this->loger instead of $this->logger" is a useful feature. And, in a lot of cases, more useful than having the language say "OK, I've created your dynamic $loger property for you", which is what currently happens. What you described there sounds like a warning and not a fatal error. Maybe that's where some of the trepidation is coming from. I know I'm less worried about the deprecation notice and more worried about what happens in PHP 9 when it's a fatal error. I can't say that this line of reasoning has its merits, but then there's no benefit to the engine itself. Issuing a warning and carry on materializing dynamic properties will never bring the original performance improvement that was part of the original state of the RFC. Which performance improvement of the "original state" of the RFC? As that was one of the questions that were not 100% answered: What are the benefits for the language. And while those 8 bit that Nikita mentioned in the "Motivation" part of the RFC look nice, he also stated that "this is a fairly long-term benefit that will require additional technical work to realize". Or did I miss something? Cheers Andreas -- ,,, (o o) +---------ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +-+ | https://hei.gl/appointmentwithandreas | +-+ OpenPGP_0xA8D5437ECE724FE5.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [PHP-DEV] Re: [RFC] Deprecate dynamic properties
Hey all On 16.11.21 10:16, Rowan Tommins wrote: On 15/11/2021 17:20, Andreas Heigl wrote: When you are testing whether writing 'X' to a property and then reading from that property gives that 'X' back, then everything should be good. I see, yes, code that is 100% perfectly tested can get away without the language performing any error checking at all - the behaviour is all guaranteed by the tests. I would be very surprised if even 1% of PHP applications can claim such comprehensive tests. The topic here was that new code can verify the declaration of a property by using tests. That does not need to happen on the language level. I was never talking about adding tests for existing code. Yes: That rips off a completely different topic: Testing "getters" and "setters". Unless you have zero business logic in your classes, testing getters and setters is absolutely not sufficient. Everywhere that accesses a private or protected property has the potential to mistype it and cause subtle bugs. That is absolutely correct. The main question is: "Do we *need* to spot this behaviour in old code"? Not "Do we *want* to spot this behaviour in old code". Yes to both questions. A number of "uses" of this feature are not actually deliberate uses which need protecting by adding the attribute, they are mistakes that are going unnoticed in those warrens of untested, un-analysed code. Those code bases are exactly the ones that benefit from the language having the run-time checks built in. That highly depends on your view-point. There are a lot of people out there that do not require that this behaviour *needs* to be spotted. Cheers Andreas -- ,,, (o o) +---------ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +-+ | https://hei.gl/appointmentwithandreas | +-+ OpenPGP_0xA8D5437ECE724FE5.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [PHP-DEV] Re: [RFC] Deprecate dynamic properties
Hey Rowan, hey all
On 15.11.21 17:52, Rowan Tommins wrote:
On 15/11/2021 16:23, Andreas Heigl wrote:
One thing, that can verify the correct working of properties, whether
that is dynamic or static ones, is testing.
Can it? I can't actually see how that would work, without also having a
way to detect when dynamic properties were accessed, which brings us
full circle. Also:
When you are testing whether writing 'X' to a property and then reading
from that property gives that 'X' back, then everything should be good.
You either typed the name of the property correctly or you have a typo
in the setter and getter (or however you set and got the value).
Nevertheless you should be able to figure out whether you accidentally
misstyped a property name somewhere as that should break the test
(unless you misstyped the name twice). ANd whether you are doing the
assignement to a static property or to a dynamic one should be
irrelevant, the reading and the writing process are the same.
Yes: That rips off a completely different topic: Testing "getters" and
"setters".
So the mistakes-part would be easy to handle.
If you are working with a million lines of code going back 20 years,
"write tests for everything" is not "easy to handle"; it's a long-term
ambition which you chip away at when priorities allow.
The intention is not to write tests for existing code. As the intention
is exactly to be able to leave existing code as it is. Otherwise the
approach to "add the Attribute and be done" would be much easier.
The intention is much more to make sure that *new* code does not write
accidentally to the wrong property. Which is what this RFC is all about.
Make sure that dynamic properties are not accidentally used.
"Logging all deprecations and warnings on a production workload",
however, *is* easy to handle. Diagnostic messages in logs are the *only*
way this behaviour will be spotted in old code.
That is absolutely correct. The main question is: "Do we *need* to spot
this behaviour in old code"? Not "Do we *want* to spot this behaviour in
old code".
What I am still missing is the differentiation between "everything is
strict and you have to explicitly opt-in to make it dynamic" and an
"everything is dynamic and you can use a marker to mark this
explicitly an intended behaviour". That would allow users to mark a
class explicitly to use dynamic features even though it would make no
difference code-wise.
I'm not sure what you mean by that. Do you mean, create the attribute,
but don't actually do anything with it? Would the plan be to deprecate
later? Never remove at all?
As currently there is no direct intention to remove the feature for
good, why should we force it? And espechialy why do we need to force
those maintinaing existing code to adapt their code?
For now the possibility could be to keep everything *as is*. Plus add an
attribute to make absolutely explicit that we want to use this feature.
The next step could then be to create a setting that will notify about
dynamic assignments in classes that are not marked by the attribute. I'm
not talking about a deprecation note here. More something like a notice
(not a warning as that is too severe!). That way the behaviour can come
up in log files. Perhaps a new Level of notice like a
"bad_coding_practice". Or we use different "lanes" of reporting. One for
notices, errors, warnings et al and one for deprecations and such
asignment-oddities.
When that has been done (should so far all be BC) and code-maintainers
have had enough time to modify their codebase (definition of "enough
time" is here clearly the main topic and needs discussion with
maintainers!) then we can talk about possibly phasing out the feature.
My 0.02€
Cheers
Andreas
--
,,,
(o o)
+-ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org |
+-+
| https://hei.gl/appointmentwithandreas |
+-+
OpenPGP_0xA8D5437ECE724FE5.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PHP-DEV] Re: [RFC] Deprecate dynamic properties
Hey Nikita. On 15.11.21 14:50, Nikita Popov wrote: [...] I hope that the new "Motivation" section clarifies things a bit, especially in regards to why "static analysis" is only a partial solution to this problem: https://wiki.php.net/rfc/deprecate_dynamic_properties#motivation Thanks for the clarification! One thing, that can verify the correct working of properties, whether that is dynamic or static ones, is testing. So when one wants to make sure that their code behaves as it should, then proper testing can help with that. So while the static analysis is one possibility, the other one is writing appropriate tests. While that will still not eliminate the usage of external tools it is fore sure something that most of the projects using modern code already implement. So the mistakes-part would be easy to handle. Being explicit on the other hand is something that I would very much appreciate. And using an Annotation for that is great. What I am still missing is the differentiation between "everything is strict and you have to explicitly opt-in to make it dynamic" and an "everything is dynamic and you can use a marker to mark this explicitly an intended behaviour". That would allow users to mark a class explicitly to use dynamic features even though it would make no difference code-wise. And that could already be implemented via a userland-shim right now which would then use the Core-Attribute as of PHP8.2 The other thing, that I noticed is that you were speaking of a possible reduction of the object-size by 8 byte. Is there a comparison of how much that would be in percent for some default applications? So is that something that actually "pays off"? Thanks again for your insights! Cheers Andreas -- ,,, (o o) +---------ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +-+ | https://hei.gl/appointmentwithandreas | +-+ OpenPGP_0xA8D5437ECE724FE5.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [PHP-DEV] Re: [RFC] Deprecate dynamic properties
On 15.11.21 14:19, Rowan Tommins wrote: On 15/11/2021 12:51, Andreas Heigl wrote: PS: Am I the only one missing whether this is a 2/3 or a 50%+1 vote in the RFC? All votes require a 2/3 majority as of https://wiki.php.net/rfc/abolish-narrow-margins Thanks! I just stumbled over the fact that some other recent RFCs still had the statement "requiring a 2/3 majority" in the "Vote" part which I was missing here. Cheers Andreas -- ,,, (o o) +-ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +-+ | https://hei.gl/appointmentwithandreas | +-+ OpenPGP_0xA8D5437ECE724FE5.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [PHP-DEV] Re: [RFC] Deprecate dynamic properties
Hea all.
On 15.11.21 10:52, Derick Rethans wrote:
Dear Internals,
On Wed, 10 Nov 2021, Nikita Popov wrote:
On Wed, Aug 25, 2021 at 12:02 PM Nikita Popov wrote:
This RFC takes the more direct route of deprecating this
functionality entirely. I expect that this will have relatively
little impact on modern code (e.g. in Symfony I could fix the vast
majority of deprecation warnings with a three-line diff), but may
have a big impact on legacy code that doesn't declare properties at
all.
I plan to open voting on this RFC soon. Most of the feedback was
positive, apart from the initial choice of opt-int mechanism, and that
part should be addressed by the switch to the
#[AllowDynamicProperties] attribute.
The voting is now open, but I think one thing was not taken into account
here, the many small changes that push work to maintainers of Open
Source library and CI related tools.
In the last few years, the release cadence of PHP has increased, which
is great for new features. It however has not been helpful to introduce
many small deprecations and BC breaks in every single release.
This invariably is making maintainers of Open Source anxious, and
frustrated as so much work is need to keep things up to date. I know
they are *deprecations*, and applications can turn these off, but that's
not the case for maintainers of libraries.
Before we introduce many more of this into PHP 8.2, I think it would be
wise to figure out a way how to:
- improve the langauge with new features
- keep maintenance cost for open source library and CI tools much lower
- come up with a set of guidelines for when it is necessary to introduce
BC breaks and deprecations.
I am all for improving the language and making it more feature rich, but
we have not spend enough time considering the impacts to the full
ecosystem.
I have therefore voted "no" on this RFC, and I hope you will too.
cheers,
Derick
After some thoughs on this RFC I have reverted my original vote and
voted "No" due to several reasons.
For one thing it is not clear to me what the benefits are. Yes: The
language evolution RFC talks about "Forbidding dynamic object
properties" but it also specifies that "there is also a lot of old code
that does not declare properties, so this needs to be opt-in"[1].
And as far as I can see from the PR associated with this RFC it will not
make life easier for the internals team. It is not like there will be
hundreds of lines code less to maintain. On the contrary. There is more
code and more logic to maintain [2].
So when the only reason for the change is that one line in the RFC ("In
modern code, this is rarely done intentionally"[3]) then that is not
enough of a reasoning for me for such a code change that requires a lot
of existing code to change.
Those that want a cleaner code can already use static code analysis to
find such issues (if not, I'm sure that there will be some analyzers
around before PHP8.2 will be around) or write appropriate tests to make
sure that they do not use undeclared properties.
While I personally would really like to deprecate dynamic properties I
believe that it is the wrong thing to do for the language. At least
given the presented arguments why we should do it.
Cheers
Andreas
PS: Am I the only one missing whether this is a 2/3 or a 50%+1 vote in
the RFC?
[1]
https://github.com/nikic/php-rfcs/blob/language-evolution/rfcs/-language-evolution.md#forbidding-dynamic-object-properties
[2] https://github.com/php/php-src/pull/7571/files
[3] https://wiki.php.net/rfc/deprecate_dynamic_properties
--
,,,
(o o)
+---------ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org |
+-+
| https://hei.gl/appointmentwithandreas |
+-+
OpenPGP_0xA8D5437ECE724FE5.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PHP-DEV] Unbreak git.php.net links?
Hey all. On 04.10.21 07:52, Hans Henrik Bergan wrote: there's also plenty of broken links on reddit to git.php.net , ref https://www.google.com/search?q=git.php.net+site%3Areddit.com it wouldn't be hard to set up a redirector parsing commit ids out of the url and redirecting to github, +1 from me. So who's going to work on it? Doesn't make sense to have 5 people work on it independently from each other ;-) Cheers Andreas -- ,,, (o o) +-ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +-+ | https://hei.gl/appointmentwithandreas | +-+ OpenPGP_0xA8D5437ECE724FE5.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [PHP-DEV] DateTimeZone silently falls back to UTC when providing seconds
Hey
On 13.09.21 13:32, Hans Henrik Bergan wrote:
What use-case does that serve?
if some country want to change their timezone for whatever reason, to some
timezone that didn't exist previously, could happen at any time really
I'm well aware that that could happen at any time really. And I'm well
aware that "at any time" also can mean "By the way, we changed 14 days ago".
But what does that mean? That means that there are different possibilities:
1. The change was announced well in advance and therefore there is a
TZDB release that already reflects that change. So whatever timezone we
are talking about: The modification is already available and can be used
via the [continent]/[city] identifier. And if we would allow all
existing offsets to be used, that one would also be available.
2. The change was not announced well in advance, so that there is no
TZDB release that reflects that change when it goes "live". You PHP
application is the least concern you have. Because the change is not
reflected *anywhere*. Not on your server, not on your database, not on
the users mobiles not on the users desktops, not in their smartwatches:
nowhere.* Yes: You would then be able to allow people to enter the
offset instead of letting them comfortably select a location near them
and extrapolate the timezone (or offset if it must be) from that. But
you are then handling data that is not officially registered, could
possibly change and might break in the future due to some differences
that the official sources defined but your user didn't know about. That
is a rabbit hole that I would not want to get into and that we should
not encourage to get into. And which is currently open and seems to be
in need of fixing.
For completeness sake there is a further option: The change was
announced well in advance but you did not yet update your PHP-version or
the timezonedb pecl package. Do so! Preferably the former but if that is
not an option at least the later!
So my question still stands:
What use-case does it serve to allow offsets that are not reflected in
the TZDB?
Again: Just my 0.02 €
Cheers
Andreas
* That almost happened some years ago. IIRC the government actually
postponed the change so the TZDB and all the upstream vendors could react.
On Sun, 12 Sept 2021 at 13:06, Andreas Heigl wrote:
Hey Benjamin, Hey All
On 11.09.21 23:58, Benjamin Morel wrote:
Before doing so, shouldn't we discuss whether it makes sense to accept
a
time-zone offset with seconds, when the granularity seems to be 15
mins?
https://en.wikipedia.org/wiki/List_of_UTC_time_offsets
— Benjamin
No need. Early timezone offsets in the timezone database are in LMT
(local
mean time), which have second granularity.
cheers,
Derick
Hi, sorry for resurrecting an old thread, but now that this bug
<https://bugs.php.net/bug.php?id=81097> has been fixed in PHP 8.0.10, I
can
see that seconds have been forbidden from DateTimeZone altogether:
https://3v4l.org/QpSln
Before forbidding seconds in brick/date-time's *TimeZoneOffset* as well
(and going against JSR-310, which this library was derived from), can I
please know why this decision was made, when as I understand it, this
goes
against your statement above?
For me the more interesting question is: "Why would one allow to create
any arbitrary Timezone-object using any offset at all?"
Currently it is even possible to declare a Timezone Object with an
Offset that has never been used anywhere on the globe. So for example
`new DateTimezone(`+11:32`) is completely valid from a coding point of
view but not from a timezone point of view. What use-case does that serve?
If one has to create a timezone-object for an existing timezone one can
create that either via `new DateTimezone('Continent/Whatever')` or via
`new DateTimezone('Etc/GMT+XX')` or via `new DateTimezone('PST')`.
This does currently not support creating offset-based timezone-objects
for areas such as Nepal or India that use an offset that currently can't
be declared via the `Etc`-Identifiers.
So a different approach would be to only support type 1 offsets that are
known to the TZDB. Everything else (including arbitrary seconds) should
result in an exception.
So I can understand to not allow arbitrary seconds at all. But IMO we
should then also not allow arbitrary minutes also.
But that's just my 0.02 €
Cheers
Andreas
--
,,,
(o o)
+---------ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org |
+--
Re: [PHP-DEV] DateTimeZone silently falls back to UTC when providing seconds
Hey Benjamin, Hey All
On 11.09.21 23:58, Benjamin Morel wrote:
Before doing so, shouldn't we discuss whether it makes sense to accept
a
time-zone offset with seconds, when the granularity seems to be 15
mins?
https://en.wikipedia.org/wiki/List_of_UTC_time_offsets
— Benjamin
No need. Early timezone offsets in the timezone database are in LMT (local
mean time), which have second granularity.
cheers,
Derick
Hi, sorry for resurrecting an old thread, but now that this bug
<https://bugs.php.net/bug.php?id=81097> has been fixed in PHP 8.0.10, I can
see that seconds have been forbidden from DateTimeZone altogether:
https://3v4l.org/QpSln
Before forbidding seconds in brick/date-time's *TimeZoneOffset* as well
(and going against JSR-310, which this library was derived from), can I
please know why this decision was made, when as I understand it, this goes
against your statement above?
For me the more interesting question is: "Why would one allow to create
any arbitrary Timezone-object using any offset at all?"
Currently it is even possible to declare a Timezone Object with an
Offset that has never been used anywhere on the globe. So for example
`new DateTimezone(`+11:32`) is completely valid from a coding point of
view but not from a timezone point of view. What use-case does that serve?
If one has to create a timezone-object for an existing timezone one can
create that either via `new DateTimezone('Continent/Whatever')` or via
`new DateTimezone('Etc/GMT+XX')` or via `new DateTimezone('PST')`.
This does currently not support creating offset-based timezone-objects
for areas such as Nepal or India that use an offset that currently can't
be declared via the `Etc`-Identifiers.
So a different approach would be to only support type 1 offsets that are
known to the TZDB. Everything else (including arbitrary seconds) should
result in an exception.
So I can understand to not allow arbitrary seconds at all. But IMO we
should then also not allow arbitrary minutes also.
But that's just my 0.02 €
Cheers
Andreas
--
,,,
(o o)
+-ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org |
+-+
| https://hei.gl/appointmentwithandreas |
+-+
OpenPGP_0xA8D5437ECE724FE5.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] $this return type
Hey Nikita On 07.09.21 12:28, Nikita Popov wrote: Hi internals, I'd like to pick up a loose thread from the future scope of the https://wiki.php.net/rfc/static_return_type RFC, the $this return type for fluent APIs: https://wiki.php.net/rfc/this_return_type I have some reservations about this (which basically come down to $this not being a proper "type", so should it be in the type system?) but I can see the practical usefulness, so I think it's worth discussing this. Regards, Nikita If we allow a $this (let's keep the actual naming out for the moment) as a returntype to clarify that it has to be the same instance that is returned, I would also either expect that the returntype 'self' does explicitly *not* allow the same instance to be returned. As that would be a huge BC break I would on the other hand also think that we should implement a returntype "!$this" to explicitly state that the contract here returns *not* the current instance but a new one. That way a lot of immutable contracts could be made more clear. What'S your or others idea regarding that? Cheers Andreas -- ,,, (o o) +-ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +-+ | https://hei.gl/appointmentwithandreas | +-+ OpenPGP_0xA8D5437ECE724FE5.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [PHP-DEV] Request for karma to vote on RFCs
Hey Mike
Am 20.07.21 um 15:11 schrieb Mike Schinkel:
>> On Jul 20, 2021, at 8:55 AM, Andreas Heigl wrote:
>>
>> Hey Mike
>>
>> Thank you for your feedback!
>>
>> Am 20.07.21 um 11:57 schrieb Mike Schinkel:
>>> Quoting the RFC
>>>
>>>> the requester has contributed to the PHP sourcecode ecosystem.
>>>
>>> You mention what types of contributions apply, but give no indication of
>>> quantity. If someone fixes one bug, does that give them voting rights? I
>>> would assume not. So is it two bugs, 10 bugs, 100?
>>
>> As the RFC is still not finished especially in terms of wording that is
>> something that definitely needs some improvements. I tried to leave it
>> as open as possible in the initial draft to have that as basis for
>> further discussions. What do you think would be an appropriate number?
>
> As I don't have voting rights, I don't think I am in an empowered position to
> make specific suggestions.
That's got nothing to do with empowerment. You raised the issue so what
would you think is an adequate number? ;-)
Whether that will be something that internals will find appropriate is a
different story, but having a base for discussion is always helpful.
>
> If I were going to design the PHP's governance I would design differently,
> but since I'm not in a role to do that I can only accept that PHP governance
> is the way that it is, and point out things I think might be problematic. >
> As for specific suggestions? I'll let others who already have a vote specify
> those.
If we leave the specs only to those with voting rights then nothing
might change as they have a fair share of work already. So proposing
something to them that they can then use as a base for discussion is
always easier than pushing others to come up with something ;-)
Cheers
Andreas
>
> -Mike
>
--
,,,
(o o)
+-ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org |
+-+
| https://hei.gl/appointmentwithandreas |
+-+
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PHP-DEV] Request for karma to vote on RFCs
ask these questions so people who might be interested in getting voting > rights would have an objective roadmap for how to get there otherwise it > would seem to just be documenting an extremely subjective process. (Which > might be all you are attempting to do?) I'm trying to create exactly that: An objective roadmap what to do to get voting rights. What I did not yet get into is the question what to do when someone did a lot of effort to get voting rights and right after that stops all efforts. Perhaps we should add a passage to the RFC regarding that as well. Thanks though for your input! Cheers Andreas -- ,,, (o o) +-ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +-+ | https://hei.gl/appointmentwithandreas | +-+ OpenPGP_signature Description: OpenPGP digital signature
Re: [PHP-DEV] Request for karma to vote on RFCs
Hey Hamza Am 20.07.21 um 13:12 schrieb Hamza Ahmad: > I am not going to critique the RFC; rather, I say that this RFC needs > a fresh rewrite because I find more like it a set of instructions. The > proposal needs to be a detailed one. It seams as if it is written > hastily. As noted in the original Email to the list, the RFC is a draft that was explicitly put onto github (and not into the PHP-Wiki) to allow working on it before putting it up on the PHP-Wiki for the discussion phase that is required for an RFC. Yes: You are right! The RFC was written hastily! It was mainly written hastily to have something as base for discussions so that we have *something* that we can then together improve over multiple iterations to make a great RFC out of it that will a) provide a consistent way for gaining voting karma and b) has a chance to be accepted when it comes to voting for or against this RFC. So the intention of this RFC is not to be the only relevant solution to a problem we might probably not even have. On the contrary: The intention is to provide something that everyone interested can improve to something great. So your input is more than welcome. Especially your input in form of a PR to improve the current version! And of course also your input in form of discussion contributions on that text. What this RFC will for sure *not* modify is the infrastructure. We have a certain infrastructure at the moment and changing that will take much more than an RFC. So this RFC also has to take that as a given and has to work around this. As great as some changes would be: we can not take them for grantend in the course of this RFC. So looking forward to your PR. Cheers Andreas -- ,,, (o o) +-ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +-+ | https://hei.gl/appointmentwithandreas | +-+ OpenPGP_signature Description: OpenPGP digital signature
Re: [PHP-DEV] Request for karma to vote on RFCs
Hey Jordan, Hey All. Am 20.07.21 um 10:07 schrieb Jordan LeDoux: > Another aspect that I thought about after reading your draft was a way to > structurally avoid concerns about stacking. I don't believe that there > would necessarily be overt efforts to grant karma to individuals to push > certain concerns to the side, however it might be worth considering if the > process could promote a variety of opinions and backgrounds. Even if such a > situation were considered unlikely, it could be worth writing such a > process with that in mind if the process involves a sponsor. > > As I said earlier, it makes sense for many reasons to require a sponsor to > get voting karma, however this may unnecessarily make the applicant > associated with their sponsor or their sponsor's history and contributions > (which could be a positive or negative to one person or the other). It also > makes it less likely that a perspective which is totally unrepresented gets > sponsored. This could also be a positive thing, as not all perspectives are > truly relevant or constructive to all the processes. But it might be worth > considering these impacts explicitly. > > It's also worth considering if people believe that this is a process that > will be iterated on or if there is a desire to get it right the first time > and stick with it. Perhaps if the intent is to iterate, or at least > explicitly revisit the criteria, the RFC could include an expiration at > which time a vote to either keep or change the process could be held, which > gives everyone clarity and certainty about the structure over a given > period. > > Those are my immediate thoughts on your rough draft. I've incorporated the changes into a PR https://github.com/heiglandreas/rfc/pull/1/files and also added these concerns to the PR description. Either I'll see to it to incorporate them or if someone else wants to create a PR to discuss those concerns I'd be happy as well. Cheers Andreas -- ,,, (o o) +-----ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +-+ | https://hei.gl/appointmentwithandreas | +-+ OpenPGP_signature Description: OpenPGP digital signature
Re: [PHP-DEV] Request for karma to vote on RFCs
Hey All Am 19.07.21 um 17:02 schrieb Andreas Heigl: > Hey All > > Am 19.07.21 um 16:34 schrieb Levi Morrison via internals: >> On Mon, Jul 19, 2021 at 2:38 AM Nikita Popov wrote: >>> >>> On Sun, Jul 18, 2021 at 8:48 PM Tobias Nyholm >>> wrote: >>> >>>> Hey. >>>> I would like to get karma to be able to vote on RFCs. I understand that >>>> voting karma isn’t usually given out to people who write their first >>>> mailing list entry. >>>> >>>> But I do believe I qualify as “Lead developers of PHP based projects >>>> (frameworks, cms, tools, etc.)” >>> >>> Hey Tobias, >>> >>> My response here is basically the same as the last time the topic came up: >>> https://externals.io/message/110936#110937 Voting is just the very last >>> step of the RFC process, at which point the proposal can no longer be >>> influenced. If you have feedback about a proposal based on your extensive >>> experience in PHP's open source ecosystem, then the discussion phase is the >>> time to provide it, while it can still influence the proposal, as well as >>> other people's view of the proposal. >> >> I second this. >> >>> At least in my personal opinion, I think it's important that people granted >>> voting rights as community representatives have at least some historical >>> involvement in RFC discussions. >> >> I agree with this, but have no specific objection to granting Tobias >> voting karma, as this is underspecified; how long should they >> participate? What kinds of involvement are appropriate? Being >> underspecified is not really their fault, and I don't feel like it >> would be an abuse to grant them voting karma, but do think it would be >> an abuse to deny them voting karma indefinitely because "we" don't get >> around to specifying it. It should be less of a decision on a >> case-by-case basis and more of a checklist. >> > > Sounds like we need an RFC to make it clearer how voting karma for the > RFC process will be granted in the future. I have created a draft for an RFC to implement future rules for granting voting karma. If you want to contribute to that, feel free to open a PR against it[1]. To be able to make the future karma grants more trnasparent this needs input from everyone: Opponoents as well as proponents! I'm looking forward to a fruitful conversation and to a great RFC that can move us to more transparency. Cheers Andreas [1] https://github.com/heiglandreas/rfc/blob/main/implement_future_rules_for_granting_voting_karma.md -- ,,, (o o) +-ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +-+ | https://hei.gl/appointmentwithandreas | +-+ OpenPGP_signature Description: OpenPGP digital signature
Re: [PHP-DEV] Request for karma to vote on RFCs
Hey All
Am 19.07.21 um 16:34 schrieb Levi Morrison via internals:
> On Mon, Jul 19, 2021 at 2:38 AM Nikita Popov wrote:
>>
>> On Sun, Jul 18, 2021 at 8:48 PM Tobias Nyholm
>> wrote:
>>
>>> Hey.
>>> I would like to get karma to be able to vote on RFCs. I understand that
>>> voting karma isn’t usually given out to people who write their first
>>> mailing list entry.
>>>
>>> But I do believe I qualify as “Lead developers of PHP based projects
>>> (frameworks, cms, tools, etc.)”
>>
>> Hey Tobias,
>>
>> My response here is basically the same as the last time the topic came up:
>> https://externals.io/message/110936#110937 Voting is just the very last
>> step of the RFC process, at which point the proposal can no longer be
>> influenced. If you have feedback about a proposal based on your extensive
>> experience in PHP's open source ecosystem, then the discussion phase is the
>> time to provide it, while it can still influence the proposal, as well as
>> other people's view of the proposal.
>
> I second this.
>
>> At least in my personal opinion, I think it's important that people granted
>> voting rights as community representatives have at least some historical
>> involvement in RFC discussions.
>
> I agree with this, but have no specific objection to granting Tobias
> voting karma, as this is underspecified; how long should they
> participate? What kinds of involvement are appropriate? Being
> underspecified is not really their fault, and I don't feel like it
> would be an abuse to grant them voting karma, but do think it would be
> an abuse to deny them voting karma indefinitely because "we" don't get
> around to specifying it. It should be less of a decision on a
> case-by-case basis and more of a checklist.
>
Sounds like we need an RFC to make it clearer how voting karma for the
RFC process will be granted in the future.
Looking forward to your inputs.
Cheers
Andreas
--
,,,
(o o)
+-ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org |
+-+
| https://hei.gl/appointmentwithandreas |
+-+
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PHP-DEV] Bugsnet
Hey All
Am 10.05.21 um 14:44 schrieb Alexander Kurilo via internals:
> On 09/05/2021 09:48, Joe Watkins wrote:
>> Morning internals,
>>
>> We have a spam problem on bugsnet, it's not a new problem. Nikita had to
>> waste time deleting 20 odd messages from bugsnet yesterday and this is a
>> common, daily occurrence. We clearly don't have time for this.
>>
>> Quite aside from spam problems, bugsnet is hidden away in a dark
>> corner of
>> the internet that requires a special login, doesn't integrate with source
>> code or our current workflow (very nicely), and doesn't get updated or
>> developed.
>
>
> So, there are 2 distinct issues: spam from bugsnet (this one can be
> mitigated by replacing current "solve a problem" challenge by something
> more sophisticated) and the bugsnet itself being a burden (which can't
> be solved quickly).
>
> Let's separate the two: this way we can have kill the spam in the short
> term and get enough time to shape out the migration plan if there's a
> consensus on the matter.
>
> What about integrating [recaptcha][1] for now? Integration is rather
> simple but there are other concerns, e.g. a third-party JS code on the
> page that accepts security issues.
If so, can we please use something else? Implementing a Honeypot or a
simple math-captcha isn't that complicated (and I assume that a person
that can provide a decent bug description can also solve a riddle like
"Enter the result of 7 plus 2")
Thanks!
Andreas
--
,,,
(o o)
+-ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org |
+-+
| https://hei.gl/appointmentwithandreas |
+-+
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PHP-DEV] Re: Bugsnet
Hey folks:
Am 09.05.21 um 09:33 schrieb Stanislav Malyshev:
> Hi!
>
[...]
>
> 1. Bug reporting templates> 2. Pre-filter on reported bugs> 3. Advanced search
> 4. Custom fields like PHP version or CVE ID
> 5. Private bugs that are accessible only to members of security team
> 6. Custom statuses (I guess can be worked around with labels, but would
> require a lot of work to make it convenient to use, default screen would
> be pretty much unusable due to clutter, as it only understands closed/open)
> 7. Ability for anybody to submit a bug without opening github account
> (yes, I know it also produces the spam problem) and assigning bugs to
> people that don't have github account (we still can accept patches from
> those, can't we?).
> 8. Statistics
>
>> It may be over optimistic, but we might get better engagement with
>> bugs on github than anywhere else also - Github is where people are
>> tending to do their business today.
>
> I think it's way to generic statement. Some people choose github for
> doing some stuff would be more accurate. I don't think I can remember
> from the top of my head any major project that uses Github as their main
> bug tracker. Maybe they exist, but I certainly can't recall any.
>
>> Github is maintained, hosted, developed, and free, and while it isn't
>> the perfect tool for the job, nothing else is either. We could spend
>> time (which we don't have) developing bugsnet, or installing some
>> other solution in a dark corner of the internet, and solve no problems
>> at all, and be burdened with the ongoing maintenance of that solution.
>
> Why we must install it in a dark corner? Maybe we should ask for some
> help from people who are willing to contribute before we decide to scrap
> the whole thing.
>
> Besides that, I am not sure I am feeling that comfortable with moving
> 100% of the infrastructure of the PHP project to a platform wholly owned
> by Microsoft, and that's where things seem to be heading. I know
> Microsoft is almost not evil now, and it has no problem with PHP
> whatsoever, but things change, and who knows what would happen in
> another 5-10 years. I am not sure hard-binding the whole project to a
> single platform owned by a single company is that great. Due to the
> distributed nature of Git, the repository hosting is very low risk - it
> could be easily moved anywhere. But having the rest of the
> infrastructure in a single point of failure does not feel great. Once we
> move in there, it would be very hard to move out.
This is for me the most interesting point. While it is rather easy to
move fastly away from Github with the source-code it will be much more
complicated to move to "somewhere else" with all of the issues.
Yes, we currently have the same problem with PRs but not "owning" our
bug-report system feels ... not right to me. Especially when there is no
way to actually turning it off due to the security bugs.
While on the other hand I think it absolutely great to have another
infrastructure part that we do not have to maintain!
My prefered way to go would be some other bug-reporting SaaS that can
integrate with github but can provide some more of what we currently
have and that also allows us to also use it for security related issues.
Just my 0.02€
Cheers
Andreas
--
,,,
(o o)
+-ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org https://hei.gl/where |
|https://hei.gl/pubkeyandreas |
+-+
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Add __toString() to DateInterval
Am 03.03.21 um 14:24 schrieb Moritz Friedrich:
>
>
>> Am 03.03.2021 um 14:01 schrieb Andreas Heigl :
>>
>> I'd rather see those classes as ValueObjects that should not have to
>> take care about their external representation. And a custom Formatter
>> that handles all the weird edge cases as a separate entity would be a
>> much easier to maintain approach. And such a Formatter can easily be
>> build in userland (I think I wrote one myself at one point) and so the
>> maintenance-burden would also not be added to internals.
>>
>> That would also apply to the DateTimeInterval::format() method but that
>> would mean a massive BC break so it is most likely out of the question.
>> Nevertheless I would prefer an external library to handle all those
>> formatting issues and treat the DateTime lib as internal ValueObjects
>
> I’d like to respectfully disagree. If we were to go down the ValueObject
> route, DateTime/DateInterval should not be able to create new instances from
> formatted strings in the first place. PHP Date classes have always been
> intertwined with their output formatting however, so this is how the
> ecosystem uses them. In that sense, I’d expect DateInterval to be able to
> return the format it was instantiated with, but it isn't.
Well. ValueObjects should be able to create new Instances of themselves
via factory methods. But that would mean a lot of tweaking at perhaps no
added benefit.
But TBH: DateTimeImmutable:fromString() instead of new
DateTimeImmutable() would be awesome... Or even better:
DateTime::fromString() with DateTimeImmutable as return type
> The PHP API may have its warts, but I prefer my warts consistent.
I feel you.
As the other Objects have a format() method why not have a format method
for DatePeriod as well? It does not need to take a parameter as there
are no different formats (at least that I could think of).
But I would rather not add more magic (methods) to PHP...
Cheers
Andreas
--
,,,
(o o)
+-ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org |
+-+
| https://hei.gl/appointmentwithandreas |
+-+
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PHP-DEV] Add __toString() to DateInterval
Hey
Am 03.03.21 um 13:05 schrieb Hans Henrik Bergan:
> if FWIW if DateTime::__toString() was just
> function __toString():string{
> return $this->format(\DateTime::RFC3339);
> }
>
> i certainly wouldn't complain.
>
> On Wed, 3 Mar 2021 at 12:16, Bruce Weirdan wrote:
>
>> On Wed, Mar 3, 2021 at 1:07 PM Moritz Friedrich wrote:
>>
>>> but I’m not too fond of the constant - all other built-in date constants
>>> translate to a string of plain format characters, which isn’t possible in
>>> this case
>>
>>
>> Adding another format character (similar to %c used by
>> DateTimeInterface::format()) would solve that.
I'd rather see those classes as ValueObjects that should not have to
take care about their external representation. And a custom Formatter
that handles all the weird edge cases as a separate entity would be a
much easier to maintain approach. And such a Formatter can easily be
build in userland (I think I wrote one myself at one point) and so the
maintenance-burden would also not be added to internals.
That would also apply to the DateTimeInterval::format() method but that
would mean a massive BC break so it is most likely out of the question.
Nevertheless I would prefer an external library to handle all those
formatting issues and treat the DateTime lib as internal ValueObjects
Cheers
Andreas
--
,,,
(o o)
+-ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org |
+-+
| https://hei.gl/appointmentwithandreas |
+-+
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PHP-DEV] Whitespace around Paamayim Nekudotayim (double colon)
Hey Matt. Am 15.02.21 um 06:14 schrieb Matthew Brown: > Hey all, > > Is there interest in prohibiting whitespace around double colons in the > next major PHP version? > > I was surprised to learn that PHP treats :: similar to ->, allowing double > colons like > > A:: > b(); > > Looking at the top 2,000 packages in Packagist I can't find any evidence of > people using a double colon with whitespace around, and my suspicion is > that the use of it is basically non-existent. > > I wonder if there's a benefit to removing a small potential footgun from > the language? I can't really see any benefit to _keeping_ it (unless it > turns out my analysis is wrong, and it's actually wildly popular). Additional whitespace means *any* whitespace. Not just line ends. And I've seen far too many codebases that use spaces around double colons (or arrows or a lot of other things) like this: A :: b(); Not allowing that on a language level just to avoid people shooting their own foot while we have enough userland tools to at least make people aware of such issues (like php_codesniffer, php-cs-fix or – perhaps even better – phpunit) feels a bit drastic to me. Cheers Andreas -- ,,, (o o) +-----ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +-+ | https://hei.gl/appointmentwithandreas | +-+ signature.asc Description: OpenPGP digital signature
[PHP-DEV] Documentation is on git
Hey folks! The PHP-Documentation has moved to git! Not at the same day as the PHP8-release but at least in the same year ;-) Nikita and myself took the last steps today to finalize what a number of people have been working on for the last at least 4 years. Thanks to Derick, Rasmus, Sara, Paul, Peter, Gabriel and a lot of others for their support, encouragement and help. So from now on there is no possibility to contribute to the documentation via SVN. All the contributions have to go via git now. Details regarding setup can be found at https://github.com/php/doc-base/blob/master/README.md This move also means that there are now mirrors of the documentation at github through which contributions can be made now. There are some minor things still waiting to happen like the revcheck (which is currently being worked on) or not all github mirrors having actually "mirrored" yet (as they need a propper commit to start the mirroring). But in general: It is done! What is the next goal now? Create the best documentation PHP has ever had! Cheers Andreas -- ,,, (o o) +-ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +-+ | https://hei.gl/appointmentwithandreas | +-+ signature.asc Description: OpenPGP digital signature
[PHP-DEV] Moving from SVN to git - finally!
Hey folks! After some years we are finally at the point to do what so many have been asking for: We will move the source-control of the PHP-Documentation from SVN to git! Tomorrow! TL;DR Tomorrow we will remove docs-karma from SVN, do a final transition and then add doc-karma to git. Then all contributions to the PHP-Documentation will be via git.php.net Slightly longer version: Throughout the last year we continuously moved the commits from SVN over to the different repositories at git.php.net. 2 Days ago we finally switched the actually creation of the docs from using the SVN-sources to using the git-sources. It was a seamless transition and the broken translations were broken before. So we managed to switch the VCS without anyone noticing ;-) But that will not be possible for the next step. As everyone that is currently contributing to the docs via SVN will need to do at least 2 things to be able to continue contributing! * Checkout the docs-base from https://git.php.net/repository/doc/base.git * Check out the english documentation from g...@git.php.net:/doc/en.git And if you are doing translations: * Check out your respective language from g...@git.php.net:/doc/[language].git Yes! You've seen that right! We moved away from the monorepo to one repo per language. As at this point in time there are access restrictions on the different languages this was a necessary move. There are pros and cons to that that were addressed when we started that voyage. And you can feel free to discuss them as soon as the transition has been made and you have found someone doing the necessary work for a further change ;-) And as git doesn't know about "revisions" we had to change one thing for the translations: So far you kept the revision of the english doc you base the translation on in the attribute "en-revision". That will now change! After the switch you will need to add the _commit-hash_ of the english doc there instead! Apart from that the translation workflow itself stays the same. We only changed the Version Control System, nothing else. So what will be the next steps now? As already mentioned: Sometime tomorrow we will switch off karma for svn.php.net. Then we will do one last transition to git and modify the repos so that the revision is replaced by the commit-hash Then we will switch karma on for git.php.net And when that is finished, we will create the github mirrors so that everyone can create PRs for the docs and the translations! That's it. Almost... As there is one thing though that is not done yet which we need some help with: The revision-check! For those of you that do not know what it is: Head over to http://doc.php.net/revcheck.php and have a look. In short: It shows how outdated a translation is. This was tightly coupled to SVN and it is much harder to convert to git as originally anticipated. So any help on that is highly appreciated! Patches for http://git.php.net/?p=web/doc.git;a=blob;f=scripts/rev.php are definitely welcome! But that is something for a new challenge! Looking forward to being able to put a decade long challenge for the community and a 4+ year challenge for me to a good end tomorrow! Let's all cross fingers that everything goes as smooth as expected! Cheers For the team: Andreas -- ,,, (o o) +-ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +-+ | https://hei.gl/appointmentwithandreas | +-+ signature.asc Description: OpenPGP digital signature
[PHP-DEV] Re: Github Mirrors of git.php.net/docs
Hey Lists, hey Nikita.
Just to give some feedback.
Am 27.12.20 um 14:59 schrieb Nikita Popov:
> On Sun, Dec 27, 2020 at 11:30 AM Andreas Heigl <mailto:andr...@heigl.org>> wrote:
>
[...]
> I don't think fixing revcheck in advance is particularly important, I
> just want to retain the current format of EN-Revisions stored in each
> file (just with git hashes instead of SVN revisions).
>
> Basically, I want to run this script after writes to SVN have been
> disabled and before writes to Git are enabled:
> https://gist.github.com/nikic/8ee88a817db794aff15adb7e07754e23 It just
> moves the hashes back into EN-Revision and drops the .en-revisions.ref
> file. It does need something like 20 minutes per repo, but it's a
> one-time cost.
>
> Does that sound reasonable to you? Basically, the plan would be:
> 1. Remove phpdoc SVN karma from everyone. (me)
> 2. Disable SVN -> Git mirroring. (you)
> 3. Run above script to move hashes back into EN-Revision and force push
> repos. (you or me)
> 4. Add Git karma for everyone. (me)
> 5. Set up GitHub mirrors (me)
> And I think this is something we could do anytime now, if I understood
> your right that the online docs are *already* being built from Git.
After Nikitas merge I transfered the changes to the euk2-box and since
the 27th of December 2020 16:30H UTC the PHP-documentation is building
from git instead of SVN.
So we are prepared to take the next step now.
@Nikita: I would like to add a step 0 to the plan which would be to
inform the docs-contributors via the docs-mailinglist about the changes
and especially about date and time of the change so that they can adapt
their local settings in advance. Feel free to drop me a direct email re.
Date and Time
Additionally I just realized that the link on each docs-page to "edit"
is linking to edit.php.net which we should then change after the move to
link to the appropriate github-repo.
Cheers
Andreas
--
,,,
(o o)
+-ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org |
+-+
| https://hei.gl/appointmentwithandreas |
+-+
signature.asc
Description: OpenPGP digital signature
[PHP-DEV] edit.php.net is down
Hey folks. Edit.php.net is down. And from the tweet I got not only for some hours (https://twitter.com/arueckauer/status/1288728325331079168) Can either anyone with access to the system (pb11.php.net) have a look or grant me access so that I can have a look? According to https://wiki.php.net/systems/pb11 the following people have access: Alexander (irker), Hannes, Michael, Martin, Philip, Rasmus, Yannick Even though I know that edit.php.net will become obsolete once we manage to get the conversion from SVN to git up and running (I'm currently struggling with http://doc.php.net/revcheck.php) it currently is the official way to contribute to the docs. So it should be up and running IMO. Thanks for a short response! Cheers Andreas -- ,,, (o o) +-ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | http://andreas.heigl.org http://hei.gl/wiFKy7 | +-+ | http://hei.gl/root-ca | +-+ signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Deprecating uniqid()
Hey Ben, hey all
Am 02.05.20 um 21:13 schrieb Ben Ramsey:
>> On May 2, 2020, at 13:57, AllenJB wrote:
>>
>> Hi all,
>>
>> I'd like to discuss deprecating uniqid()
>>
>> I believe it's dangerously bad a doing "what it says on the tin". New
>> developers still reach for it and do not read the warnings on the manual
>> page (or if they do, don't fully understand how bad it is).
>>
>> For older codebases that still rely on it, a userland replacement can be
>> easily implemented (and could be published on Packagist).
>>
>> I noticed there was an RFC [0][1] brought up 2 years ago, but was never
>> voted on. Does anyone know why this was?
>>
>> [0] https://externals.io/message/102097
>> [1] https://wiki.php.net/rfc/deprecate-uniqid
>>
>> Is there interest in deprecating this function?
>>
>> If not deprecation, how could it be (further) "improved"? My first thought
>> is to make the "more entropy" option enabled by default (the argument could
>> remain so that it can be disabled by codebases that rely on the lower length
>> and can take the tradeoffs).
>
>
> Instead of deprecating and removing it, would anyone be opposed to replacing
> the internals of the function so that it uses `random_bytes()` under the
> hood, while all other functionality remains the same?
I'D rather deprecate it and give a clear advice on what to use instead
(i.e. in the docs) than changing the internal behaviour and break code.
As replacement I could think of showing people the way to UUIDs.
As the function itself was never intended for cryptographically secure
values I would not see random_* functions or the like as a replacement.
My 0.02 €
Cheers
Andreas
--
,,,
(o o)
+-ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org http://hei.gl/wiFKy7 |
+-+
| http://hei.gl/root-ca |
+-+
signature.asc
Description: OpenPGP digital signature
[PHP-DEV] Moving the PHP Documentation to git
Hey internals and docs-people. About 2 months ago (on Feb. 11th to be more precise) I wrote an email to these lists containing the current state of the transfer of the docs from SVN to git (see https://externals.io/message/108350#108504). All the technical things have been solved so far and what is now missing is the actual move of building the documentation from git instead of SVN. As described in the last Email that is something that requires access to euk2.php.net and therefore requires an action from one of the people with access to that machine: bjori, mgdm, mj, nilgun, philip, salathe, sobak, tyrael and yannick (you have been CC'd). Alternatively someone could grant me access to that machine so that I can figure out how to do the changes myself (possibly breaking the system ) Or we simply leave everything as it is. Then we need someone to add every new docs contributor to the authors-list on svngit.php.net so that the conversion doesn't break. Now it's up to you Cheers Andreas -- ,,, (o o) +-ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | http://andreas.heigl.org http://hei.gl/wiFKy7 | +-+ | http://hei.gl/root-ca | +-+ signature.asc Description: OpenPGP digital signature
[PHP-DEV] The state of the PHP-Group (was: OSI approval for PHP 3.01 license)
Hey all Am 07.03.20 um 13:20 schrieb Christoph M. Becker: > On 05.03.2020 at 17:46, Ben Ramsey wrote: > >>> I’ve submitted a formal request for “legacy approval” to the OSI >>> license-review list, according to their policies. >>> >>> http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-March/004716.html >> >> >> Here's a question from the OSI list that I cannot answer on my own: >> >> >>>> If this version is approved, will the steward voluntarily deprecate >>>> version 3.0, and if not, and if 3.01 is approved, should 3.0 be >>>> involuntarily deprecated? >> >> >> The “steward” is the PHP Group. I know that Rasmus, Zeev, and Sascha are >> still active on this list, but I don’t know what the protocol is for making >> this decision. Would this need a simple RFC for the internals community to >> vote on? If that’s the route, I’m happy to put together a draft. > > Could some member(s) of the PHP Group please comment on this. Would this be a good point in time to to question the current state of the PHP-Group as defined in https://www.php.net/credits.php? If the PHP-Group as a loose connection of veterans (used in the best sense here) is responsible for decisions like the one at hand here we might have to think about how that group is put together. Especially when of the ten people in the group only 3 seem to be still active. It looks like a bad idea to wait until no one is active any more and we need response from that group... Please note that this is not about breaking down the group or questioning the responsibilities (even though those as well seem to be rather loosely defined). This is merely about whether there should be some fresh blood in the group to reduce the bus-factor. Cheers Andreas -- ,,, (o o) +-ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | http://andreas.heigl.org http://hei.gl/wiFKy7 | +-+ | http://hei.gl/root-ca | +-+ signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Re: OSI approval for PHP 3.01 license
Hey All. Am 04.03.20 um 10:05 schrieb Christoph M. Becker: > On 03.03.2020 at 23:13, Matthew Sheahan wrote: > >> My team’s ability to use the phpdbg utility hinges on OSI approval of its >> license. Language at https://www.php.net/license/ indicates that the PHP >> 3.01 license is OSI approved, but OSI disagrees; >> https://opensource.org/licenses/alphabetical shows approval only of the PHP >> 3.0 license. (The fact that 3.0 and 3.01 are substantively identical is no >> use to us at all.) OSI, for its part, indicates that per >> https://opensource.org/approval, only the “License Steward” of the PHP 3.01 >> license has standing to request that it be reviewed, via OSI’s License >> Review mailing list. >> >> >> >> I would like to see the license review process there carried out as soon as >> possible, and might suggest that the apparent inaccuracy of the claim of OSI >> approval for 3.01 on php.net is a matter for concern. >> >> >> >> Publicly available information does not yield any insight into who the >> “License Steward” of the PHP 3.01 license might be, or how to contact any >> responsible party at the PHP Group. If anyone can direct me appropriately >> or forward this message to someone who can, I would very much appreciate it. >> Thanks! >> Does anyone here remember why the changes to the license where done in the first place? The commit was done on the 1st of Jan. 2006 (at least according to https://github.com/php/php-src/commit/56567d31b331d3ab7814b36867579116eb14da86#diff-9879d6db96fd29134fc802214163b95a) and I couldn't find that commit on svn.php.net any more to have more information on it... Insight would be highly appreciated ;-) Cheers Andreas -- ,,, (o o) +-ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | http://andreas.heigl.org http://hei.gl/wiFKy7 | +-+ | http://hei.gl/root-ca | +-+ signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Proposal for a new basic function: str_contains
Am 03.03.20 um 14:29 schrieb Nicolas Grekas: > Le mar. 3 mars 2020 à 11:04, Rowan Tommins a > écrit : > >> On Tue, 3 Mar 2020 at 08:46, Andreas Heigl wrote: >> >>> >>> While it is mainly aimed at being a mere convenience-function that could >>> also be easily implemented in userland it misses one main thing IMO when >>> handling unicode-strings: Normalization. >>> >>> >> >> While I would love to see more functionality for handling Unicode which >> didn't treat it as just another character set, I don't think sprinkling it >> into the main string functions of the language would be the right approach. >> Even if we changed all the existing functions to be "Unicode-aware", as was >> planned for PHP 6, the resulting API would not handle all cases correctly. >> >> In this case, a Unicode-based string API ought to provide at least two >> variants of "contains", as options or separate functions: >> >> - a version which matches on code point, for answering queries like "does >> this string contain right-to-left override characters?" >> - at least one form of normalization, but probably several >> >> If there was serious work on a new string API in progress, a freeze on >> additions to the current API would make sense; but right now, the >> byte-based string API is what we have, and I think this function is a >> sensible addition to it. >> > > > FYI, I wrote a String handling lib, shipped as Symfony String: > - doc: https://symfony.com/doc/current/components/string.html > - src: https://github.com/symfony/string > > TL;DR, it provides 3 classes of value objects, dealing with bytes, code > points and grapheme cluster (~= normalized unicode) > > It makes no sense to have `str_contains()` or any global function able to > deal with Unicode normalization *unless* the PHP string values embed their > unit system (one of: bytes, codepoints or graphemes). > > With this rationale, I agree with Rowan: PHP's native string functions deal > with bytes. So should str_contains(). Other unit systems can be implemented > in userland (until PHP implements something similar to Symfony String in > core - but that's another topic.) str_contains as it currently is implemented can also easily be implemented in userland. That was my reasoning. I would think otherwise would it take unicode into account as that's much harder to implement in userland. And I didn'T want to start a new discussion, I merely wanted to explain the reasoning behind my decission. Cheers Andreas -- ,,, (o o) +-ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | http://andreas.heigl.org http://hei.gl/wiFKy7 | +-+ | http://hei.gl/root-ca | +-+ signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Proposal for a new basic function: str_contains
Hey all.
Just a short note why I voted against the current implementation of the
str_contains functionality.
While it is mainly aimed at being a mere convenience-function that could
also be easily implemented in userland it misses one main thing IMO when
handling unicode-strings: Normalization.
It is correct, that the binary representation of the string "äöüß"
within the string "Täöüßtstring" seems to be the same and that a simple
`strpos('Täöüßtstring', 'äöüß')` results in a not-false result.
But using unicode it might be that the two strings are using different
normalizations. So for the human eye the two strings look (almost)
identical but internaly they are completely different (and even
mb_strpos might not be able to detect the similarity).
See https://3v4l.org/fasO4 for more information.
As we are creating new functionality here it would have been great to
solve this issue. But as it is IMO merely a convenience add on that can
easily be implemented in userland I vote against it.
Cheers
Andreas
Am 17.02.20 um 15:23 schrieb Rowan Tommins:
> On Mon, 17 Feb 2020 at 13:38, Pierre Joye wrote:
>
>>
>> Btw, while some mbstring references I I mentioned, I do like the ICU search
>> implementation as well.
>>
>> http://userguide.icu-project.org/collation/icu-string-search-service
>>
>> It handles a lot of cases based on locales.
>>
>
>
> That's a lovely example of why treating Unicode as a character encoding is
> the wrong mindset.
>
> I would love to see more people using ext/intl rather than ext/mbstring,
> and more ICU features like this being included.
>
> Regards,
>
--
,,,
(o o)
+-ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org http://hei.gl/wiFKy7 |
+-+
| http://hei.gl/root-ca |
+-+
signature.asc
Description: OpenPGP digital signature
Re: [PHP-DEV] Make var_dump() use serialize_precision
Am 18.02.20 um 12:20 schrieb Nikita Popov:
> Hi internals,
>
> https://github.com/php/php-src/pull/5172 changes var_dump() to use
> serialize_precision instead of precision to dump floating-point numbers.
>
> To recap: serialize_precision defaults to -1, which will print exactly as
> many floating-point digits as are needed to represent the number
> accurately. precision defaults to 14, which will print a shorter but
> potentially inaccurate float representation.
>
> The motivation here is that var_dump() is debugging functionality and
> should print values as accurately as possible. The single most common bug
> report we receive is some kind of variation on:
>
> $sum = 0.1 + 0.2;
> var_dump($sum); // float(0.3)
> var_dump($sum == 0.3); // bool(false) WTF???
>
> After this change, this would instead be:
>
> $sum = 0.1 + 0.2;
> var_dump($sum); // float(0.30004)
> var_dump($sum == 0.3); // bool(false) Makes sense...
>
> I have little hope that developers will suddenly start understanding
> floating-point numbers, but at least this should reduce the amount of
> confusion.
>
> Does anyone see an issue with doing this change?
You mean apart from people now filing bugs how var_dump() can output
such a nonsensical number from such an easy equation? And that it again
shows that PHP is not a real programming language (unlike JavaScript)
and should never be used at all?
Nope ;-)
Cheers
Andreas
PS: I'd absolutely appreciate the change!!!
--
,,,
(o o)
+-ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org http://hei.gl/wiFKy7 |
+-+
| http://hei.gl/root-ca |
+-+
signature.asc
Description: OpenPGP digital signature
[PHP-DEV] Re: Moving the documentation to git
Hey Internals and docs-folks On Monday we finished the first important step of moving the documentation to git. Nikita created all the missing repos and Peter provided me with push access to all those repos via the phpdocbot account. I then cloned all currently active language-repos using an authors map from SVn to git and pushed the result to git.php.net/doc. Now the docs are continuously fetched from SVN, converted to git and pushed to their respective repos. The english docs every 15 minutes and the translations every two hours. Currently the leading system (the Single Source Of Truth) is still SVN! But people can now already contribute via git to the docs as – at least as far as I understood – the process of pushing changes from git to SVN is more or less automated (correct me if I'm wrong here, Nikita/Peter). Now the next steps are to move the toolage from SVN to git. That means: * Switch Source Retrieval for Docs building on docs.php.net from svn.php.net to git.php.net * Switch Generation of revcheck-files from svn to git (Work is already done at https://github.com/phpdoctest/doc-base/blob/master/scripts/revcheck.php) * Verify that everything works as expected When that is finished and accepted we can move over to the next stage: * Switch Source Retrieval for Docs building on rsynv.php.net from SVN to git * Setup Mirroring and processes to merge PRs from GitHub to documentation git. * Rewrite setup-instructions and send email to docs team regarding new process And then we can finally make SVN readonly. (and the cronjobs on svngit.php.net need top be shut down) I've also added the ToDo list to https://github.com/phpdoctest/meta/wiki/todo, so that everyone can follow the process. As the next steps need access to euk2.php.net which I currently do not have, I'd need someone to actually do those next tasks. Access – according to the wiki – have bjori, mgdm, mj, nilgun, philip, salathe, sobak, tyrael and yannick. I'd be very happy if one of you could ping me so that we can check the next steps. Thank you all for the support during the last weeks. Cheers Andreas Am 04.02.20 um 08:09 schrieb Andreas Heigl: > Hey folks. > > During the last year I took a bit of time aside to bring the > documentation from SVN to git. And about a month ago I informed the > DOCs-Mailinglist about the current status and the fact that we are ready > to move to the next step[1]. Now some tasks need to be done by people > with appropriate karma to be able to get on with the whole thing, but > all the background tasks are done and awaiting further processing. > > Sadly there was no response so far. Neither on the email as such nor on > the different tasks. > > So the main question is now, how the PHP-Project wants to go on with > moving the documentation from SVN to git? Is there any interest in > continuing this project? And if so, who can either take on the necessary > steps or provide us with the appropriate credentials and access rights > that we can do them ourselves? > > Thanks for reading and looking forward to the results. > > Cheers > > Andreas > > [https://news-web.php.net/php.doc/969387429] > -- ,,, (o o) +-----ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | http://andreas.heigl.org http://hei.gl/wiFKy7 | +-+ | http://hei.gl/root-ca | +-+ signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Re: Moving the documentation to git
Hey Nikita. Am 04.02.20 um 15:49 schrieb Nikita Popov: > On Tue, Feb 4, 2020 at 3:46 PM Andreas Heigl wrote: > >> Hey Nikita. >> >> Am 04.02.20 um 15:20 schrieb Nikita Popov: >>> On Tue, Feb 4, 2020 at 2:08 PM Nikita Popov >> wrote: >>> >>>> On Tue, Feb 4, 2020 at 1:48 PM Andreas Heigl wrote: >>>> >>>>> Hey Nikita, hey all. >>>>> >>>>> Am 04.02.20 um 12:11 schrieb Nikita Popov: >>>>>> On Tue, Feb 4, 2020 at 8:09 AM Andreas Heigl >>>>> <mailto:andr...@heigl.org>> wrote: >>>>> >>>>>> >>>>>> Hi Andreas, >>>>>> >>>>>> would you mind pushing the current en/de repos to >>>>>> https://github.com/phpdoctest/en and de so it's possible to see how >>>>> they >>>>>> look like now? >>>>> >>>>> Find the repos (as they should be on git.php.net would I have access) >> at >>>>> https://github.com/phpdoctest/de and https://github.com/phpdoctest/en >>>>> >>>>> They are updated after each run of the converter-tool which currently >>>>> runs every two hours. >>>>> >>>> >>>> Thanks! It looks like currently the author mapping from svn -> git is >>>> missing, which also means we don't get the mapping to github accounts. >> I'll >>>> send you the author mapping file I have (which is unfortunately >> somewhat >>>> dated, maybe Peter has a newer one?), it would be great to preserve >>>> authorship in a meaningful way. >>>> >>>> Nikita >>>> >>> >>> In a previous mail you mentioned that the current EN-Revision is now >> being >>> tracked in a separate file. Could you point out which files that is, >>> because I didn't see it in the repo. Or is it part of some other repo? >> >> The en-revision is tracked in the translated repos only, not in the >> english one. >> >> Have a look at >> https://github.com/phpdoctest/de/blob/master/.en-revisions.ref > > > Thanks! I think what confused me is that the last commit to the repo ( > https://github.com/phpdoctest/de/commit/10286e6f55405503cecfeae2e91fa030a57a5906) > modifies an EN-Revision in a file, but there is no corresponding update to > .en-revisions.ref. Shouldn't there be one? There should be one and I have noticed that as well. I will need to redo the steps anyhow this weekend to add the correct authors-file and will then also have a look at why that is not updated accordingly. Do you know which file that update was in? > > PS: I have done "Step 1" and created all the necessary repositories in > git.php.net. Awesome! Thank you! Who has commit access to that repo so far? I would then start pushing the data as soon as I have fixed the authors list. At least to the translations. @salathe, shall I also force-push to the neglish master-branch or shall I push to a different branch in the en-repo? Cheers Andreas > > Nikita > -- ,,, (o o) +-ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | http://andreas.heigl.org http://hei.gl/wiFKy7 | +-+ | http://hei.gl/root-ca | +-+ signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Re: Moving the documentation to git
Hey Nikita. Am 04.02.20 um 15:20 schrieb Nikita Popov: > On Tue, Feb 4, 2020 at 2:08 PM Nikita Popov wrote: > >> On Tue, Feb 4, 2020 at 1:48 PM Andreas Heigl wrote: >> >>> Hey Nikita, hey all. >>> >>> Am 04.02.20 um 12:11 schrieb Nikita Popov: >>>> On Tue, Feb 4, 2020 at 8:09 AM Andreas Heigl >>> <mailto:andr...@heigl.org>> wrote: >>> >>>> >>>> Hi Andreas, >>>> >>>> would you mind pushing the current en/de repos to >>>> https://github.com/phpdoctest/en and de so it's possible to see how >>> they >>>> look like now? >>> >>> Find the repos (as they should be on git.php.net would I have access) at >>> https://github.com/phpdoctest/de and https://github.com/phpdoctest/en >>> >>> They are updated after each run of the converter-tool which currently >>> runs every two hours. >>> >> >> Thanks! It looks like currently the author mapping from svn -> git is >> missing, which also means we don't get the mapping to github accounts. I'll >> send you the author mapping file I have (which is unfortunately somewhat >> dated, maybe Peter has a newer one?), it would be great to preserve >> authorship in a meaningful way. >> >> Nikita >> > > In a previous mail you mentioned that the current EN-Revision is now being > tracked in a separate file. Could you point out which files that is, > because I didn't see it in the repo. Or is it part of some other repo? The en-revision is tracked in the translated repos only, not in the english one. Have a look at https://github.com/phpdoctest/de/blob/master/.en-revisions.ref Cheers Andreas -- ,,, (o o) +-ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | http://andreas.heigl.org http://hei.gl/wiFKy7 | +-+ | http://hei.gl/root-ca | +-+ signature.asc Description: OpenPGP digital signature
[PHP-DEV] Re: Moving the documentation to git
Hey Nikita, hey all. Am 04.02.20 um 12:11 schrieb Nikita Popov: > On Tue, Feb 4, 2020 at 8:09 AM Andreas Heigl <mailto:andr...@heigl.org>> wrote: > > Hi Andreas, > > would you mind pushing the current en/de repos to > https://github.com/phpdoctest/en and de so it's possible to see how they > look like now? Find the repos (as they should be on git.php.net would I have access) at https://github.com/phpdoctest/de and https://github.com/phpdoctest/en They are updated after each run of the converter-tool which currently runs every two hours. Cheers Andreas -- ,,, (o o) +---------ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | http://andreas.heigl.org http://hei.gl/wiFKy7 | +-+ | http://hei.gl/root-ca | +-+ signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Re: What about a magic __toArray() method?
Hey all.
Instead of adding more magic I personally like the approach of
explicitness more and your suggest adding an interface "Arrayable"
(naming is hard and this might not be the best name) instead. Whether
that interface then defines a `__toArray()`-method or something entirely
different is then a different matter.
Additionally this would be in line with Nicolas RFC regarding
"Stringable" (https://wiki.php.net/rfc/stringable)
Just my 0.02€
Cheers
Andreas
Am 04.02.20 um 08:18 schrieb Midori Koçak:
> Or we can deprecate __toString() method at all and detect cast events
> instead. Would it make more sense? Something like this __casted().
>
> P.S: I saw the previous conversation but hence now we have types, it would
> make sense.
>
> Midori
>
> On Tue, 4 Feb 2020 at 08:15, Midori Koçak wrote:
>
>> As you know we have __toString method that runs whenever an object is
>> typecasted to string or it is directly echoed.
>>
>> >
>> $class = (new class{
>> public function __toString(){
>> echo "casted\n";
>> return "mahmut\n";
>> }
>> });
>>
>> echo $class;
>> $casted = (string)$class;
>>
>> /*
>> prints:
>> casted
>> mahmut
>> casted
>> mahmut
>> */
>>
>>
>> As you know toArray() method implemented when an object is converted into
>> and array and most of the time when a plain data object is sent to
>> front-end.
>>
>> Having a magic method like __toString called __toArray would be useful to
>> detect and act on conversion events.
>>
>> Roughly it would be like:
>>
>> >
>> $class = (new class{
>> public function __toArray(){
>> echo "casted\n";
>> return
>> [
>> 'key'=>'value'
>> ];
>> }
>> });
>>
>>
>> $casted = (array)$class;
>> print_r($casted);
>>
>> /*
>> prints:
>> Array
>> (
>> [key] => value
>> )
>> mahmut
>> */
>>
>> What would you think? I think it would add value.
>>
>
--
,,,
(o o)
+-ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org http://hei.gl/wiFKy7 |
+-+
| http://hei.gl/root-ca |
+-+
signature.asc
Description: OpenPGP digital signature
[PHP-DEV] Moving the documentation to git
Hey folks. During the last year I took a bit of time aside to bring the documentation from SVN to git. And about a month ago I informed the DOCs-Mailinglist about the current status and the fact that we are ready to move to the next step[1]. Now some tasks need to be done by people with appropriate karma to be able to get on with the whole thing, but all the background tasks are done and awaiting further processing. Sadly there was no response so far. Neither on the email as such nor on the different tasks. So the main question is now, how the PHP-Project wants to go on with moving the documentation from SVN to git? Is there any interest in continuing this project? And if so, who can either take on the necessary steps or provide us with the appropriate credentials and access rights that we can do them ourselves? Thanks for reading and looking forward to the results. Cheers Andreas [https://news-web.php.net/php.doc/969387429] -- ,,, (o o) +-ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | http://andreas.heigl.org http://hei.gl/wiFKy7 | +-+ | http://hei.gl/root-ca | +-+ signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [Discussion] Unifying Documentation and UI-Based Editing
d their willingness to change their beloved workflows into account. Especially on OSS projects where people usually don't get paid to work on that. This attempt is in my eyes a great idea that should be discussed on the documentation mailinglist whether it is an attempt for a future modification of the files, processes and workflows. But in the meantime I sadly don't see it helping in the current project of moving the currently existing documentation from SVN to git. My 0.02 € Cheers Andreas PS: > > > Pre-Emptive Q > = > > 1. Why do certain blocks have the ability to add multiple text sections? > This was a design choice to help with translation. While it would have > been possible, and frankly easier to make each major part only have one > translation for each, these could become quite large, and I think it > makes sense to split them up. > > Therefore, sections like notes and examples have the ability to extend > themselves with a multiple text sections, where each one is tracked and > translated independently. > > > > 2. But I love XML > At present, I have only made a one-way conversion process that takes XML > and turns it into the necessary JSON for rendering, and it’s my > intention to improve it some to be able to pull in existing translations > from multiple languages (using common identifiers such as a parameter > name as a point of reference to join the data). > > It would be possible to write something that did this in reverse, and > took the JSON and turned it back into valid Docbook XML. If this makes > any sense in the long run I am not convinced as I think writing the > renderers is a lot easier in JSON, and it can be committed to GIT all > the same if it's pretty-printed so it's not all mushed up on one line. We currently *have* renderers in place. They are working quite well. Moving to JSON means we have to *rewrite* them which binds working forces. > > > 3. Validation? > Definitely needs to have JSON Schema applied to it before it's put into > use. We *have* validation by XML-Schemata. Moving to JSON means we have to *redo* it again. Which – again – binds working forces > > > 4. Source? > Sauce? Tomato Sauce? https://github.com/marandall/phpdoc-editor > > Avoid the XML parsing code. It's pure cancer. A personal note here: An XSLT file would be able to do the transition without the need for PHP ;-) -- ,,, (o o) +-ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | http://andreas.heigl.org http://hei.gl/wiFKy7 | +-+ | http://hei.gl/root-ca | +-+ signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] Prevent disruptions of conversations
Hey Midory, Hey all. Am 20.09.19 um 09:30 schrieb Midori Koçak: > Wow. > > A RFC that it's motivation is to prevent beginners from asking questions. Is it? I'm citing from the RFC: > This explicitly wouldn't apply to 'positive' conversations. e.g. if someone > asks for help, and you want to contact them in private to offer them help, > that would be fine. It's only when a conversation is adversarial that the > conversation should remain on list. It is not motivated at preventing beginners from asking questions. On the contrary. IMO it encourages them to do so. But one of the first questions should perhaps be who would be willing to answer newcomer-questions off-list. I believe that a newcomer will learn much more with one or two mentors than by asking all the questions to the list. So the motivation is *not* to stop beginners to ask questions, but to prevent the list being flooded by questions that can be handled in a better way for all involved people. > > That's horrible. Yes it would be, would that be the intention. I'd like to repeat myself here: The intention is to keep disruptions to a minimum. > > I rather prefer a CoC. What about this? https://confcodeofconduct.com/ Let's tackle one goal after the other. While having a CoC is a good thing, that I personally would like the PHP-Project to have, I still remember the last discussions on that topic and they were as disruptive as the current ones And I – again – want to quote the RFC on that: > This RFC does not propose a comprehensive Code of Conduct, which will take a > significant amount of effort to draft carefully. This is a stop-gap measure > to allow us to use the internals newsgroup to be able to ship PHP 7.4 > successfully. Cheers Andreas -- ,,, (o o) +-----ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | http://andreas.heigl.org http://hei.gl/wiFKy7 | +-+ | http://hei.gl/root-ca | +-+ signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] Prevent disruptions of conversations
Hey Stas, Hey All. Am 20.09.19 um 08:00 schrieb Stanislav Malyshev: > Hi! > >> taken part of). So given that track record, along with how the project >> philosophy generally is, I do not see abuse being a problem, even the >> sligtest. > > There are a lot of things that I thought our project philosophy does not > admit, but turns out I have been wrong. I don't see why if we are > already discussing banning people for questioning the holy RFC process, > we'd need any "abuse" to have a problem. I think mere "use" of this RFC, > as written - to ban people for expressing "wrong" thoughts that somebody > (who?) deems "disrupting" - IMO would be abuse enough. And if it's never > intended to be used, then why have it? As you yourself mentioned, we've > dealt with rare disruptive individuals before it without too much > problem and without dramatic speech code RFCs. Clearly, this is meant to > go further than that. And that direction is scary to me. "we" have not dealt with disruptive people, IIRC someone took action and removed them. "without too much problem"... I start to ask myself whether I read the same mailinglist as you... "rare disruptive individuals"... Again I ask myself whether I read the same mailinglist... "without dramatic speech code"... Yes. That was exactly the problem. No process that was agreed on *before* shit hits the fan. No one wants to ban people "for questioning the whole RFC process". A ban is something that *can* occur *after* people have tried other means of making the person in question aware of their disruptive behaviour *and nothing changed*. *After* that *everyone with a vote* can decide on whether that behaviour validates a ban. To me it looks like you are trying to make this RFC look like it tries to force a ban on people that want to contribute. While this is not the idea of the RFC I ask myself why you are so strongly against trying to find a way to get a less disruptive email-list. A toxic and disruptive email-list that drives the creation of PHP not only drives people away that would like to contribute to the language itself but also drives people away that might want to use PHP for their projects but are not sure about whether the language is such a good choice if that is the tone of development. People will leave PHP because they are not sure whether PHP has a future when the people creating the language can't even decide on how to talk to one another... Just my 0.02 € Cheers Andreas > -- ,,, (o o) +-ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | http://andreas.heigl.org http://hei.gl/wiFKy7 | +-+ | http://hei.gl/root-ca | +-+ signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Changing fundamental language behaviors
Hey Zeev.
I'm not that deep into @internals and might not get the subtle subtext.
English is not my native tongue so I might phrase things in a way that
doesn't transport the whole meaning of my thoughts. But your Mail really
left me curious:
On Thu, 12 Sep 2019 at 10:44, Zeev Suraski wrote:
> I was really really hoping that we will avert having to dive into this and
> instead go for the alternative solution that was proposed of changing
> default php.ini error levels. But since the RFC went on to a vote - we
> need
> to make something clear.
>
>
>
> The RFC process was never, ever meant to handle fundamental changes to the
> language. It was meant to deal predominantly with additions to the
> language, as can be inferred from numerous parts in the phrasing. As I
> mentioned in the past - it wasn't even intended to deal with simpler
> deprecations, but it appears that the cat is out of the bag on this one.
> However, the fact the cat is out, doesn't mean we'll let a tiger waltz out
> of the same bag. Using the RFC to deprecate fundamental behaviors of the
> language - such as how the language deals with undefined variables - is
> simply off the table.
Given the fact that you have the authority to say so, what actually *is*
the process then to make "fundamental changes to the language"?
>
>
>
> You may be wondering, in that case, what processes do we have to deal with
> such changes then? The answer is simple. We don't. We don't have to have
> them either - the fundamental language behaviors are here to stay.
But we still need processes to define which are the "fundamental
language behaviours". And as change is the only constant in
software-development, these "fundamental language behaviours" might, can
and probably should be changeable. I'm not saying they need to change,
but it has to be possible to change them. Otherwise we would still
program business-logic in C as that was Rasmus' fundamental idea IIRC
(Correct me if I'm wrong)
>
> Deprecating the ability to rely on the expected default value of
> uninitialized variables falls squarely in that category.
>
>
>
> Reclassifying a notice to a warning is a possibility - people's code will
> still run, and they'll be able to continue using these behaviors going
> forward as well if they want to (perhaps with minor tweaks to error
> reporting levels). Turning a notice to an error isn't reclassifying an
> error level. It's deprecating a behavior - and we're not talking about
> some
> esoteric extension, but a documented, well-defined, fundamental behavior of
> the language for over two decades. The fact many of you think it's
> horrible
> does not change that. Deprecating such fundamentals is simply outside of
> the mandate of internals@, regardless of whatever majority appears to
> exist
> in favor of it at a given time.
>
>
>
> Similarly - adding typed variables - is certainly a future option.
> Changing
> PHP to require typed variables (without opting in) - is well outside of the
> internals@ mandate.
So tell us, what is *insight* the @internals mandate. And who has the
mandate to change the things @internals does not have the mandate to.
From what i see you tell us (@internals) "You're not allowed to do so,
but I will not tell you who *is* allowed." So for me that raises two
main questions:
1. Who then has the mandate to do so?
2. By what authority are you making this statement?
I'm looking forward to your answers.
Cheers
Andreas
>
>
>
> For areas like that - our options are either doing nothing, or providing
> opt-in mechanisms to cater to stricter-loving audiences. I'm all for the
> 2nd option, but there is no 3rd.
>
>
>
> Zeev
--
,,,
(o o)
+-ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org http://hei.gl/wiFKy7 |
+-+
| http://hei.gl/root-ca |
+-+
signature.asc
Description: OpenPGP digital signature
Re: [PHP-DEV] [VOTE] Strict operators directive
Am 09.07.19 um 12:06 schrieb Christian Schneider: > Am 09.07.2019 um 11:30 schrieb Marco Pivetta : >> I wasn't sure about the full implications of this, but after some thought, >> the worst that can happen is excessive strictness, requiring to drop a >> single declaration on top of a file > > When you drop the declaration on top of the file the semantics of your > operators suddenly change, e.g. > "42" < "7" > changes from true to false and you get subtle bugs. > > And if you try to read other people's code (or even try to copy/paste it) > then make sure you keep in mind which mode they are programming in. But that's the same for `declare(strict_types=1);` Cheers Andreas -- ,,, (o o) +---------ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | http://andreas.heigl.org http://hei.gl/wiFKy7 | +-+ | http://hei.gl/root-ca | +-+ signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Re: Checkout phpdoc
Am 25. Juni 2019 23:41:42 MESZ schrieb Benjamin Morel
:
>By the way, is there any work in progress to migrate the PHP manual to
>Git?
>The docs <https://www.php.net/git.php>only say:
>
>The PHP manual is still currently hosted on SVN, although it will be
>> migrated to Git in the future.
>
>
>I'd love to be able to fix things in the PHP manual with a simple PR;
>the
>current process has always repelled me.
>
>Ben
>
>On Tue, 25 Jun 2019 at 11:10, Sascha Schumann <
>sascha.schum...@myrasecurity.com> wrote:
>
>> I have disabled SNI for the upstreams on svn2.php.net.
>>
>> If the problem persists, please provide a way to reproduce the issue.
>>
>> Thanks
>> Sascha
There is a small team of people currently working on moving the docs to git.
Due to the tight integration of SVN into the workflow it's not as easy as we
all thought to do the actual move.
For more infos feel free to head over to https://github.com/phpdoctest/meta
Cheers
Andreas
--
,,,
(o o)
+-ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org https://bit.ly/wiFKy7 |
+-+
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] The real world ...
Am 13.06.19 um 15:30 schrieb Sjon Hortensius:
> FWIW - hiding database passwords (when using PDO) would be possible when
> https://github.com/php/php-src/pull/2684 gets included
I was more thinking of a more general approach as PDO is not the only
place where passwords are transfered. So having a generic Password-VO
that could be used like a password-string for BC but would not show up
in stack-traces - or at least not the cleartext-password - might improve
the security aspect regardless of where the password will be used. Yes,
at one point the cleartext-password needs to be handed over to the VO
and before that it will appear in stack-traces.
I did a userland-implementation but it still requires to hand over the
cleartext-password to relevant functions in PHP and there the stacktrace
can again leak the password. So having such a functionality in the core
would improve things.
Cheers
Andreas
>
> Cheers,
> Sjon
>
> On Thu, Jun 13, 2019 at 9:56 AM Andreas Heigl wrote:
>
>> Hey All
>>
>> Am 13.06.19 um 09:41 schrieb Nikita Popov:
>>> On Thu, Jun 13, 2019 at 9:35 AM Lester Caine wrote:
>>>
>>>> Seen in the wild ... company name sanitised
>>>>
>>>> Warning: mysqli::mysqli(): (HY000/2002): No such file or directory in
>>>> /home/888/public_html/system/library/db/mysqli.php on line 7
>>>>
>>>> Fatal error: Uncaught exception 'Exception' with message 'Error: >>> />Error No: ' in /home/888/public_html/system/library/db/mysqli.php:10
>>>> Stack trace: #0
>>>> /home/888/public_html/system/nitro/core/nitro_db.php(29):
>>>> DB\MySQLi->__construct('localhost', '888_4y65f5...',
>>>> 'J?vJr+j5iCju-bo...', '888_4y65f5...', '3306') #1
>>>> /home/888/public_html/system/nitro/core/nitro_db.php(13):
>>>> NitroDb->__construct('mysqli', 'localhost', '888_4y65f5...',
>>>> 'J?vJr+j5iCju-bo...', '888_4y65f5...', '3306') #2
>>>>
>> /home/888/public_html/system/storage/modification/system/library/db.php(11):
>>>>
>>>> NitroDb::getInstanceWithParams('mysqli', 'localhost', '888_4y65f5...',
>>>> 'J?vJr+j5iCju-bo...', '888_4y65f5...', '3306') #3
>>>> /home/888/public_html/system/framework.php(36):
>>>> DB->__construct('mysqli', 'localhost', '888_4y65f5...',
>>>> 'J?vJr+j5iCju-bo...', '888_4y65f5...', '3306') #4
>>>> /home/888/public_html/vqmod/vqcache/vq2-system_startup.php(124):
>>>> require_once('/home/888 in
>>>> /home/888/public_html/system/library/db/mysqli.php on line 10
>>>> 你的代码出错了：
>>>>
>>>> I presume something has been updated that they have not been aware of
>>>> since it's library file that triggered the warning ... but it's not the
>>>> first time in recent years I've seen this sort of information on
>>>> commercial sites and while my own clients just get white screens, those
>>>> are created by the likes of Wordpress when 'automatic updates' happen.
>>>>
>>>> Many years ago the response was "well don't update", but 'current
>>>> practice' takes that out of OUR hands! So isn't it time that the
>>>> triggering exceptions like this did produce a more user secure response
>>>> to protect against leaks like this and provide a better alternative than
>>>> a white screen?
>>>>
>>>> In the case of this live site, I actually placed an order as it was only
>>>> some links that triggered the fault, which may explain why they were not
>>>> even aware there was a problem :( From the 'development' side, NitroDb->
>>>> should obviously be handling the problem anyway.
>>>>
>>>
>>> display_errors=Off in production.
>>>
>>
>> While that makes absolute sense perhaps thinking whether there is a way
>> to mark password-parameters in core-functions and hide them in
>> Stack-traces might improve security as that would also hide
>> user-provided credentials in log-files.
>> That would not target userland methods/functions. Though having a
>> Core-Value-object for credentials might even allow *that*
>>
>> Just my 0.02 €
>>
>> Cheers
>>
>> Andreas
>> --
>> ,,,
>> (o o)
>> +---------ooO-(_)-Ooo-+
>> | Andreas Heigl |
>> | mailto:andr...@heigl.org N 50°22'59.5&qu
Re: [PHP-DEV] The real world ...
Hey Lester, hey All
Am 13.06.19 um 10:36 schrieb Lester Caine:
> On 13/06/2019 08:55, Andreas Heigl wrote:
>>> display_errors=Off in production.
>
> Which give a white screen ... fine for security but useless for people
> using the site!
>
>> While that makes absolute sense perhaps thinking whether there is a way
>> to mark password-parameters in core-functions and hide them in
>> Stack-traces might improve security as that would also hide
>> user-provided credentials in log-files.
>> That would not target userland methods/functions. Though having a
>> Core-Value-object for credentials might even allow*that*
>
> Sanitising things would be a nice to have especially where log files are
> on 'cloud' storage, but the ability to give an end user some indication
> that there is a problem WHILE display_errors=Off would be helpful? I
> know the white screen problem has been discussed many time over the
> years ...
>
> Personally I STILL use display_errors=on and just make sure that
> sensitive information is not displayed in the stack. Most of the time it
> IS just the warnings one gets and clients can report them and see they
> are cleared ... so some sort of middle ground between off and on would
> be helpful?
If you're so keen on providing the user something to see without having
to use display_errors=on: Have you had a look at
https://php.net/register_shutdown_function ?
You can always use that to figure out whether there was a fatal error
and then display something nice to the user.
No leaked stacktrace, no leaked credentials, user is informed, everyone
is happy :-)
Cheers
Andreas
--
,,,
(o o)
+-ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org http://hei.gl/wiFKy7 |
+-+
| http://hei.gl/root-ca |
+-+
signature.asc
Description: OpenPGP digital signature
Re: [PHP-DEV] The real world ...
Hey All
Am 13.06.19 um 09:41 schrieb Nikita Popov:
> On Thu, Jun 13, 2019 at 9:35 AM Lester Caine wrote:
>
>> Seen in the wild ... company name sanitised
>>
>> Warning: mysqli::mysqli(): (HY000/2002): No such file or directory in
>> /home/888/public_html/system/library/db/mysqli.php on line 7
>>
>> Fatal error: Uncaught exception 'Exception' with message 'Error: > />Error No: ' in /home/888/public_html/system/library/db/mysqli.php:10
>> Stack trace: #0
>> /home/888/public_html/system/nitro/core/nitro_db.php(29):
>> DB\MySQLi->__construct('localhost', '888_4y65f5...',
>> 'J?vJr+j5iCju-bo...', '888_4y65f5...', '3306') #1
>> /home/888/public_html/system/nitro/core/nitro_db.php(13):
>> NitroDb->__construct('mysqli', 'localhost', '888_4y65f5...',
>> 'J?vJr+j5iCju-bo...', '888_4y65f5...', '3306') #2
>> /home/888/public_html/system/storage/modification/system/library/db.php(11):
>>
>> NitroDb::getInstanceWithParams('mysqli', 'localhost', '888_4y65f5...',
>> 'J?vJr+j5iCju-bo...', '888_4y65f5...', '3306') #3
>> /home/888/public_html/system/framework.php(36):
>> DB->__construct('mysqli', 'localhost', '888_4y65f5...',
>> 'J?vJr+j5iCju-bo...', '888_4y65f5...', '3306') #4
>> /home/888/public_html/vqmod/vqcache/vq2-system_startup.php(124):
>> require_once('/home/888 in
>> /home/888/public_html/system/library/db/mysqli.php on line 10
>> 你的代码出错了：
>>
>> I presume something has been updated that they have not been aware of
>> since it's library file that triggered the warning ... but it's not the
>> first time in recent years I've seen this sort of information on
>> commercial sites and while my own clients just get white screens, those
>> are created by the likes of Wordpress when 'automatic updates' happen.
>>
>> Many years ago the response was "well don't update", but 'current
>> practice' takes that out of OUR hands! So isn't it time that the
>> triggering exceptions like this did produce a more user secure response
>> to protect against leaks like this and provide a better alternative than
>> a white screen?
>>
>> In the case of this live site, I actually placed an order as it was only
>> some links that triggered the fault, which may explain why they were not
>> even aware there was a problem :( From the 'development' side, NitroDb->
>> should obviously be handling the problem anyway.
>>
>
> display_errors=Off in production.
>
While that makes absolute sense perhaps thinking whether there is a way
to mark password-parameters in core-functions and hide them in
Stack-traces might improve security as that would also hide
user-provided credentials in log-files.
That would not target userland methods/functions. Though having a
Core-Value-object for credentials might even allow *that*
Just my 0.02 €
Cheers
Andreas
--
,,,
(o o)
+-ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org http://hei.gl/wiFKy7 |
+-+
| http://hei.gl/root-ca |
+-+
signature.asc
Description: OpenPGP digital signature
Re: [PHP-DEV] Wiki display problem
Am 03.06.19 um 17:07 schrieb Sascha Schumann: > As there are other protocols beside http/https running on news.php.net > (NNTP), we unfortunately cannot switch the whole subdomain to the cdn. How would you like to switch to the CDN? By DNS? Or we need to create a separate DNS-Entry for NNTP (nntp.php.net). I'd need to check how much reconfiguration that'd mean though... And that might mean that others will need to change their endpoints from news.php.net to nntp.php.net. IIRC externals.io f.e. uses NNTP to retrieve the messages Cheers Andreas -- ,,, (o o) +-ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | http://andreas.heigl.org http://hei.gl/wiFKy7 | +-+ | http://hei.gl/root-ca | +-+ signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Wiki display problem
Looks like the stylesheets are loaded from shared.php.net which still seems to be on an old certificate. Therefore the styles are not loaded Who can have a look into that? Cheers Andreas Am 03.06.19 um 12:52 schrieb Joe Watkins: > I think this may be related to the ssl issues from earlier today, may have > been overlooked ? > > Cheers > Joe > -- ,,, (o o) +-----ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | http://andreas.heigl.org http://hei.gl/wiFKy7 | +-+ | http://hei.gl/root-ca | +-+ signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Re: [RFC] Allow throwing exceptions from __toString()
Hey Nikita, hey all Am 13.05.19 um 16:05 schrieb Nikita Popov: > On Tue, Apr 30, 2019 at 3:32 PM Nikita Popov wrote: > >> Hi internals, >> >> I've already brought up this topic on list a couple of weeks ago... I've >> now updated the implementation based on feedback at the time, and turned >> this into a proper RFC: >> >> https://wiki.php.net/rfc/tostring_exceptions >> >> Regards, >> Nikita >> > > If there's no more comments here, I'd like to start voting on this RFC > tomorrow. As the change is technically a BC-break (as you state in the RFC) I wondered why the target is PHP7.4 and not 8. So far I didn't find a discussion on that but I might not have dug deep enough. So if this has already been discussed then I'd really appreciate a hint to the discussion. Thanks Andreas -- ,,, (o o) +-ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | http://andreas.heigl.org http://hei.gl/wiFKy7 | +-+ | http://hei.gl/root-ca | +-+ signature.asc Description: OpenPGP digital signature
