Re: [PHP-DEV] PDO_Firebird: use C++?
On Sat, Aug 10, 2024 at 4:15 PM Christoph M. Becker wrote: > So what do you think? Should we use C++ to access the new APIs, or > stick with C (and include the required declarations in PDO_Firebird)? > There's at least one another extension that requires C++ - intl. And it's a much more used one compared to FB. So I think the language itself is fine, at least as long as it's used only to interface with a third-party C++ library. -- Best regards, Max Semenik
Re: [PHP-DEV] [RFC][Discussion] NotSerializable attribute
On Wed, Jan 3, 2024 at 10:11 AM Nicolas Grekas
wrote:
>
> Regarding the inheritance-related behavior ("The non-serializable flag is
> inherited by descendants"), this is very unlike any other attributes, and
> this actively prevents writing a child class that'd make a parent
> serializable if it wants to.
>
> To me, if this is really the behavior we want, then the attribute should
> be replaced by a maker interface.
> Then, a simple "instanceof NotSerializable" would be enough instead of
> adding yet another method to ReflectionClass.
>
As explained in the RFC, this implementation hooks to the already existing
feature. Additionally, checking a bit in zend_class_entry::ce_flags is much
faster than checking inheritance.
> this actively prevents writing a child class that'd make a parent
serializable if it wants to.
Wouldn't this violate LSP?
--
Best regards,
Max Semenik
Re: [PHP-DEV] [RFC][Discussion] NotSerializable attribute
On Sat, Dec 9, 2023 at 7:18 PM Niels Dossche wrote: > If you instead put #[NotSerializable] on the parent class MyClass, then > the child class won't be serializable even if you implement the > serialization methods in the child. > Is this intentional? If yes, this should probably be clarified in the text. Elaborated about the inheritance in the RFC and added a test around it in the PR. On Sat, Dec 9, 2023 at 7:29 PM Larry Garfield wrote: > My main concern is that, as noted, *most* classes probably aren't > realistically serializable. Basically any service class should never be > serialized, ever, and anything that depends on a service class should never > be serialized, ever. So for this attribute to have the desired effect, it > would need to be added to most classes in a codebase. Which seems... like > a lot of work. In an ideal world serializability would be opt-in, but we > do not live in that world. > Indeed, adding it to every service would be an annoying overkill, but I wanted to use it on classes that should *really* not be (de)serialized. On Sun, Dec 10, 2023 at 2:46 AM G. P. B. wrote: > Moreover, having this as an attribute means, that even without adding a new > method to ReflectionClass, you could determine via Reflection if this class > is serializable or not. > Because currently, the only way to know if it is *actually* serializable is > to call serialize() on the object and see what happens. > I've amended the RFC with proposed ReflectionClass additions. -- Best regards, Max Semenik
[PHP-DEV] [RFC][Discussion] NotSerializable attribute
Hi, I'd like to propose a new attribute, #[NotSerializable]. This functionality is already available for internal classes - userspace should benefit from it, too. The RFC: https://wiki.php.net/rfc/not_serializable Proposed implementation: https://github.com/php/php-src/pull/12788 Please let me know what you think. -- Best regards, Max Semenik
Re: [PHP-DEV] Filesystem path APIs
On Fri, Dec 8, 2023 at 11:45 AM Lanre Waju wrote: > So your suggestion for simple file stuff is to download composer? > Not necessarily, but I'd like to have more discussion of pros and cons. -- Best regards, Max Semenik
Re: [PHP-DEV] Filesystem path APIs
On Wed, Dec 6, 2023 at 10:20 PM Niels Dossche wrote: > Hi internals > > I'd like to start a pre-RFC discussion about filesystem path APIs in PHP. > The reason I bring this up is because of this recent feature request: > https://github.com/php/php-src/issues/11258 > > The feature request is about the following: > We already have some functions to work with paths in PHP, e.g. basename, > dirname, realpath. > We do not have some common path APIs that you can find in other languages > like: path_join to join paths and path_normalize to normalize paths. > We have a lot of commonly used functionality that's successfully fulfilled by Composer packages - does this really have to be core functionality? I understand the argument about batteries included, but across mainstream languages you can always find examples of something that sounds like it should really be there, but it isn't. -- Best regards, Max Semenik
Re: [PHP-DEV] [RFC] [Discussion] Change the edge case of round()
This sounds like a subtle breakage to a lot of code. Could you elaborate the motivation for such change? One sentence doesn't seem enough. Also, have you tried assessing how much existing code might be affected? On Mon, Oct 23, 2023 at 2:19 PM Saki Takamachi wrote: > Sorry, I posted a completely unrelated URL. > > Correct url: > https://wiki.php.net/rfc/change_the_edge_case_of_round > > Regards. > > Saki > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > -- Best regards, Max Semenik
Re: [PHP-DEV] Sanitize filters
пн, 3 окт. 2022 г., 03:18 David Gebler : > At a glance, I think all the examples mentioned in this thread have better > existing alternatives already in core and could just be deprecated then > removed. But it's worth asking, is that what we're talking about here, or > is there a suggestion of replacing the filter API with a more modern, > object API? > Is there a compelling need to have this in the core, as opposed to Composer packages? The ecosystem has changed a lot since the original function was introduced. >
Re: [PHP-DEV] Global php.net login system with oAuth
My impression was that every homebrewed part of infrastructure suffers from lack of maintainer (man|woman|person)power. In such conditions, adding more things to maintain sounds risky. What about more third-party OAuth instead? For a lot of use cases you mentioned, using GitHub login sounds more attractive to me. Pros: it's a de-facto standard for open source collaboration, PHP uses GH already. Cons: third-party dependence, some people still have reservations about Microsoft specifically. Note that I'm not proposing going GitHub login only, I'm just suggesting an alternative to PHP OAuth. On Thu, May 19, 2022 at 8:57 PM Aaron Junker wrote: > Hi all > > I was not able to find the original thread for the idea to create a global > php.net login[1] and since the last update to this was 5 years ago, I'm > starting a new thread. > > The original idea is to create an own oAuth system. But setting up and > running an own oAuth system takes many resourceful > > Best regards > Aaron > > [1] https://wiki.php.net/ideas/phplogin > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > -- Best regards, Max Semenik
Re: [PHP-DEV] PHP Community to support Ukraine and help to stop Russian agression
On Thu, Mar 3, 2022 at 9:14 PM Eugene Sidelnyk wrote: > Maybe we'd create an RFC, create an poll and decide this way? Each of these options would require some time, and time is something not we don't have plenty of. If such a banner appears two weeks from now, how much sense would it make? Can at least we agree on something uncontroversial, like a banner encouraging people to donate to humanitarian efforts? -- Best regards, Max Semenik
Re: [PHP-DEV] PHP Community to support Ukraine and help to stop Russian agression
Each of these options would take some time, and time is what On Thu, Mar 3, 2022 at 9:14 PM Eugene Sidelnyk wrote: > Maybe we'd create an RFC, create an poll and decide this way? > > On Thu, Mar 3, 2022, 8:10 PM Alain D D Williams wrote: > > > On Thu, Mar 03, 2022 at 07:56:39PM +0200, Eugene Sidelnyk wrote: > > > > > If you, as PHP community, do not do anything about it, it would mean > that > > > you don't care. Well, everyone who writes php internals is for > discussion > > > of php internals only doesn't care and probably won't. > > > > Not true, I do care. I have done several things, eg: the Ukraine flag is > > on my > > own web site. > > > > However: I do not believe that it is right for this to be on the php.net > > web > > site. PHP is not either a political organisation nor something with a > high > > public profile: we are not FIFA. If we support Ukraine who else do we > > support. > > > > We can encourage that those on this list should show their support in > > their own > > way. We can not put it stronger than that; we might also find that some > on > > this > > list might support what Putin is doing, we must respect their views - if > so > > then discussion with them should be elsewhere - not on this list. > > > > I am very sympathetic, but I think that PHP should avoid this issue. > > > > -- > > Alain Williams > > Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, > IT > > Lecturer. > > +44 (0) 787 668 0256 https://www.phcomp.co.uk/ > > Parliament Hill Computers Ltd. Registration Information: > > https://www.phcomp.co.uk/Contact.html > > #include > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: https://www.php.net/unsub.php > > > > > -- Best regards, Max Semenik
Re: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion
On Tue, Jan 25, 2022 at 2:47 AM Mark Randall wrote: > Let's open a discussion as to what we might want to do in the future, > and depending on how things shake out, we can decide what route to take > with regards to bringing RFCs to vote. My personal opinion: there should be no old style errors, warnings or notices. I don't want to have any more situations like "Oh, there was something wrong with your code. Hope you'll notice this in your error logs. Meanwhile, the app will just kinda limp along, likely resulting in bogus data/behavior." There should only be E_DEPRECATED for things that will change in a future release and E_ERROR for rare situations that can't be reasonably handled with exceptions (like uh, unhandled exceptions and OOM errors). Everything else should be an exception, period. -- Best regards, Max Semenik
Re: [PHP-DEV] RFC: Add `final class Vector` to PHP
On Fri, Sep 17, 2021 at 5:10 AM tyson andre wrote: > Hi internals, > > I've created a new RFC https://wiki.php.net/rfc/vector proposing to add > `final class Vector` to PHP. Thank you so much, Tyson - I love your proposal. Since Ds was mentioned, I've added it to your benchmark (code and complete results at https://gist.github.com/MaxSem/d0ea0755d6deabaf88c9ef26039b2f27): Appending to array: n= 1048576 iterations= 20 memory=33558608 bytes, create+destroy time=0.369 read time = 0.210 result=10995105792000 Appending to Vector:n= 1048576 iterations= 20 memory=16777304 bytes, create+destroy time=0.270 read time = 0.270 result=10995105792000 Appending to SplStack: n= 1048576 iterations= 20 memory=33554584 bytes, create+destroy time=0.893 read time = 0.397 result=10995105792000 Appending to SplFixedArray: n= 1048576 iterations= 20 memory=16777304 bytes, create+destroy time=2.475 read time = 0.340 result=10995105792000 Appending to Ds\Vector: n= 1048576 iterations= 20 memory=24129632 bytes, create+destroy time=0.389 read time = 0.305 result=10995105792000 Another comparison with Ds, I wonder if an interface akin to Ds\Sequence[1] could be added, to have something in common with other future containers. - [1] http://docs.php.net/manual/en/class.ds-sequence.php -- Best regards, Max Semenik
Re: [PHP-DEV] RFC: autoconst
вс, 1 авг. 2021 г., 14:22 Serhii Smirnov : > instead of defining constants like: > const FOO = 'FOO'; > > they could be defined like: > autoconst FOO; // defines a constant FOO with the value 'FOO' Sorry, but I'm not a fan of this proposal. Features should not be aiming at minor savings of keystrokes at the expense of readability and maintainability. Remember, we write code once but afterwards it might end up being read hundreds of times. This proposal makes code less readable, and unintuitively works differently from enums where cases without explicit values don't default to anything. Also, modifiers could be useful: > autoconst uppercase foo; // defines a constant foo with value 'FOO' > autoconst lowercase FOO; // defines a constant FOO with value 'foo'; > > and maybe: > autoconst camelcase FOO_BAR; // defines a constant FOO_BAR with value > 'fooBar' > autoconst snakecase fooBar; // defines a constant fooBar with value > 'foo_bar' > This one saves even fewer keystrokes and harms maintainability even more: imagine you're debugging your program and you've dumped some value. You see "MyConstant". Now you search the code for the source of that value but find nothing because instead of MyConstant there's only MY_CONSTANT. >
Re: [PHP-DEV] Type casting syntax
On Mon, Jul 12, 2021 at 11:20 PM Mike Schinkel wrote: > It seems you have just illustrated why in reality we really do not need > type casting/assertions in PHP given its current features, because we > already have what we need. > Heh, nope - you asked for handling of such cases without exceptions, I obliged. My plans were around different usage scenarios. In any case, I'm not making a proposal at this point, I'm just enquiring about syntax. If I ever get something proposable done, I'll make a formal RFC. -- Best regards, Max Semenik
Re: [PHP-DEV] Type casting syntax
On Mon, Jul 12, 2021 at 8:01 PM Mike Schinkel wrote:
> Additionally in Go a type assertion can return a second value which is
> boolean telling if the type assertion succeeded. Not having this would
> effectively moot the benefit to a type assertion if you had to wrap with
> try{}catch{} in case it failed.
>
Not necessarily:
if ($obj instanceof MyClass) {
// We know its type here
} else {
// Try something else
}
--
Best regards,
Max Semenik
Re: [PHP-DEV] Type casting syntax
I was planning to propose something closer to
On Mon, Jul 12, 2021 at 2:19 AM Larry Garfield
wrote:
> What are the use cases for integrated object to object (ie, class to
> class) conversion in PHP? Rust's type system is a very different beast, so
> its casting logic makes more sense there. I'm not entirely clear on what
> the use case is in PHP. When would that be superior to "just write an
> asFoo() method and move on with life"?
>
> Scalar conversion I can see, but every time someone suggests adding
> siblings to __toString(), there's major pushback.
>
I was thinking of something akin to many compiled languages' approach of
"consider this expression is now of that type, and throw an exception if
it's not". An example of this approach from Benjamin's proposal of old^
$service = (EmailService) $diContainer->get('email.service');
Instead of
/** @var EmailService $service */
$service = $diContainer->get('email.service');
if (!$service instanceof EmailService) {
throw new TypeError('Expected instance of EmailService, ...');
}
--
Best regards,
Max Semenik
[PHP-DEV] Type casting syntax
I've been thinking about extending PHP's cast syntax to user-defined types,
e.g. not only (int)$foo but also (MyClass)$foo. Currently, a T_STRING in
parentheses is always treated as a constant - would it be acceptable to
hijack this syntax when used in unary operation context, i.e. "(" T_STRING
")" expr? If not, any other alternatives?
--
Best regards,
Max Semenik
Re: [PHP-DEV] Re: Bugsnet
On Sun, May 9, 2021 at 11:58 AM Rowan Tommins wrote: > Can we do a throwaway import of a few hundred bugs to a test repo, and see > what that might look like? Is there a dump of public issues available somewhere? The closest to sufficient data export I can find is e.g. https://bugs.php.net/rss/bug.php?id=70549&format=xml but it lacks comments even though the code is supposed to include them too. -- Best regards, Max Semenik
Re: [PHP-DEV] Re: Bugsnet
On Sun, May 9, 2021 at 11:58 AM Rowan Tommins wrote: > This is my instinct as well - Github Issues seems to be adequate as a > lightweight bug tracker, but how well will it scale, and how much will we > miss "advanced" features like separately searchable and reportable fields > and statuses? Lots of large projects use GitHub for bug tracking: Go, Rust, Kubernetes - seems to work well enough for them. > Are we better off looking for a SaaS that can provide something more > full-featured - Mantis, Phabricator, Trac, Bugzilla, YouTrack, etc? > Half of these (Mantis, Trac and especially Bugzilla) are already obsolete, migrating to either of them wouldn't be future-proof. If some people here doubt the future of GitHub, probably only Atlassian or JetBrains SaaS solutions can be assumed to be on the same order of magnitude of longevity as GH. -- Best regards, Max Semenik
Re: [PHP-DEV] [RFC] Partial function application
On Sun, Apr 25, 2021 at 10:26 PM Larry Garfield
wrote:
> https://wiki.php.net/rfc/partial_function_application
Amazing, I've wanted this for so long! Have you considered extending this
syntax to OOP, e.g. $obj->method(?) or SomeClass::staticMethod(?)?
On Sun, Apr 25, 2021 at 10:51 PM Olle Härstedt
wrote:
> Nice. :) Are there any other motivating use-cases besides pipe
> operator (that are relevant for web dev)?
One reason I'm personally excited about this proposal is that it would
allow static analysis in more cases, e.g.
$param = 'fooBar'; // What's this string? A user name? Elon Musk's favorite
color? Text of US Constitution?
somefunc($param);
function somefunc($cb) {
$cb(123, 'meh'); // What parameter types does this accept?
}
Allowing syntax like $param = fooBar(?, ?); would indicate clearly what
this variable receives. Analysis tools would then be able to check if such
a function exists and whether it would receive parameters of expected types.
--
Best regards,
Max Semenik
Re: [PHP-DEV] [VOTE] Object scoped RNG implementation
The "Proposed Voting Choices" section title needs an update. чт, 1 апр. 2021 г., 07:39 Go Kudo : > Hello everyone. > > Object scoped RNG RFC vote is now open. > https://wiki.php.net/rfc/object_scope_prng > > The deadline for voting is April 15. > > Previous discussions can be viewed below. > > https://externals.io/message/112765 > https://externals.io/message/112819 > https://externals.io/message/113720 > > Regards, > Go Kudo >
Re: [PHP-DEV] Changes to Git commit workflow
On Tue, Mar 30, 2021 at 3:29 AM Stanislav Malyshev wrote: > Hi! > > On 3/29/21 4:49 AM, Max Semenik wrote: > > Would it also make sense if direct pushes (bypassing the pull requests > > system) were disallowed completely? I can see multiple problems with > direct > > pushes: > > This is possible. In fact, there are Git bots that make it easier (e.g. > prow: https://github.com/kubernetes/test-infra/tree/master/prow) - I am > using such system over Github at my $DAYJOB and it's generally working > well. It even has its own built-in karma-like system. However, it has > some downsides, as the experience shows: > > 1. Quick management patches, typofixes, release management patches, etc. > become more high friction processes. > 2. Setup and configuration of such system involves some time investment > by some knowledgeable people, and it has certain learning curve (though > once it is set up, it's pretty easy to use). > 3. Somebody knowledgeable needs to maintain it, as periodically bots can > get stuck and need a gentle kick to continue. > 4. CI needs to be very stable and clean for having CI pass as gateway to > merge, otherwise a flaky test can block all work in the repo for days. > 5. Managing multiple active branches can be a pain. > > None of these are critical, and we could start small and build it > incrementally, of course. > We don't even have to use bots - GitHub allows you to require passing CI and/or approving reviews to merge. -- Best regards, Max Semenik
Re: [PHP-DEV] Changes to Git commit workflow
On Mon, Mar 29, 2021 at 1:53 AM Nikita Popov wrote: > changes should be pushed directly to GitHub rather than to git.php.net. Would it also make sense if direct pushes (bypassing the pull requests system) were disallowed completely? I can see multiple problems with direct pushes: 1) Someone trying to sneak in malicious code, like in the current incident (rarest but most damaging problem) 2) One dev pushes something, another dev disagrees, while the discussion continues, the potentially problematic commit stays on. Pre-merge reviews are much more natural for discussions. 3) Direct push bypasses CI to break tests, PRs can't be merged until the cause is identified and resolved (seems to be happening quite often) In my roughly one year around, I can now recall instances of each of these problems in php-src. -- Best regards, Max Semenik
Re: [PHP-DEV] What should we do with utf8_encode and utf8_decode?
On Sun, Mar 21, 2021 at 10:08 PM Kamil Tekiela wrote: > I think we really do not need to keep these functions. As for the > alternative that we can offer, iconv seems to be doing exactly the same > thing and even better. mb_convert_encoding does the same but also silently > ignores invalid characters. So we already offer plenty of alternatives. We > don't need to add anything new. > Just a quick reminder that it's possible to compile PHP without mbstring and intl, which means that some hosts will provide PHP without these extensions, and some packagers make them available as separate packages that users can't or don't know how to install. Maybe we've got an opportunity to think about making these extensions mandatory? -- Best regards, Max Semenik
Re: [PHP-DEV] [RFC] Autoloader Classmap
On Tue, Mar 16, 2021 at 2:01 AM Christian Schneider wrote: > If the number of classes to load is indeed that big that the function call > overhead is significant enough (I agree with Levi that some numbers > illustrating what we're talking about would be nice), wouldn't that be a > case for class preloading to really speed things up? Preloading doesn't work in every situation, for example Wikipedia depends on one class corresponding to multiple files for progressive deployments; the right file will be determined at runtime. This is not something the preloader can do, AFAIU. For people who are unable to take advantage of I was actually thinking of proposing adding a PSR-4 autoloader to PHP core. -- Best regards, Max Semenik
[PHP-DEV] Re: Refactoring run-tests.php
On Fri, Jun 5, 2020 at 6:41 PM Max Semenik wrote: > I was thinking about making some improvements to our venerable test > runner, however I wasn't feeling confident about improving the present code > base. Instead, I decided to attempt to refactor it. > > Here's my work in progress: https://github.com/MaxSem/run-tests > Aaand, here's first step: https://github.com/php/php-src/pull/6671 As requested, I'll submit changes in small chunks and keep everything in one file. Note: the plans of making a perfect refactor in a separate repository were definitely a mistake on my part due to the constant need to stay up to date with php-src. I'm thus backporting my changes there and will continue new changes as they're ready. -- Best regards, Max Semenik
Re: [PHP-DEV] Re: Improving PRNG implementation.
On Sun, Dec 20, 2020 at 6:45 AM zeriyoshi wrote: > Thanks cmb. I have created a first draft of an RFC. I think I've covered > all the necessary requirements, but I'd like to know if there are any > problems. > https://wiki.php.net/rfc/object_scope_prng A few IMHO comments: * Namespaces are controversial. There were multiple discussions and RFCs about introducing them for new functionality but nothing came out of it. Still probably worth adding an option for \PHP\PRNG to the vote, or something like that. * The "Which set of PRNGs should be provided as standard?" vote seems vague to me. Are you proposing to add only one algorithm? Why? Also, the adding just interfaces option makes no sense because there's Composer for things that don't require a C implementation. * "One possible solution is to implement the PRNG in pure PHP. There is actually a userland library [1], but it is not fast enough for PHP at the moment. (However, this may be improved by JIT)" - this definitely needs a comparison because implementation in C is only needed for performance reasons. * Method names: you don't need to emulate the conventions from non-OOP code, e.g. string_shuffle() --> strShuffle and array_rand() --> arrayRand(). Use a more naturally readable convention like shuffleString(). * The return value in "function shuffle(array &$array): bool" means that if something goes wrong, callers will have no idea what it is. Just throw an exception. * If the classes are namespaced, don't prefix their names, e.g. PRNGInterface --> RandomGenerator (yay, so many opportunities for bikeshedding!) * Perhaps it's worth mentioning other languages using this pattern, e.g. Java[1] and C#[2]. * Do you have evidence of widespread demand for this functionality? Usage statistics for the userland implementation you mentioned[3] don't look that hot. -- [1] https://docs.oracle.com/javase/8/docs/api/java/util/Random.html [2] https://docs.microsoft.com/en-us/dotnet/api/system.random?view=net-5.0 [3] https://packagist.org/packages/savvot/random
Re: [PHP-DEV] [RFC] Enumerations
Thank you so much for moving this forward, Larry and Ilija! I myself have tried to draft my proposal at https://wiki.php.net/rfc/enum_v2 which has aspects both similar and different from yours. And "v2" is another indicator that this feature is desired by many, so yay. On Sat, Dec 5, 2020 at 2:25 AM Larry Garfield wrote: > https://wiki.php.net/rfc/enumerations A few comments: * Having to write "case" everywhere is extremely verbose, I can't think of a popular language that requires so much typing in this area. Can the keyword be omitted completely? * Performance concern: I suspect that most developers will not use the advanced features from this proposal and your future plans much, instead they will want to use it in very simple contexts, e.g. "$order->calculateWeight(Weight::Gross)". Would every such call require an object allocation and initialization? What about comparisons, would expressions like "if ($cardType === Suit::Clubs) ..." require a new object? * What do you think about the part of my proposal that allows omitting enum name where it's obvious from context, e.g. "pick_a_card(Clubs)" if the declaration of pick_a_card() requires a parameter of type Suit? -- Best regards, Max Semenik
Re: [PHP-DEV] Literal types RFC
пн, 5 окт. 2020 г., 02:38 Bogdan Ungureanu :
>
> function getStatus(): "draft" | "published" { }
>
It sounds that what you're really asking for is enums, e.g.
enum Status {
Draft,
Published
};
function getStatus(): Status { ... }
>
Re: [PHP-DEV] Request for couple memory optimized array improvements
On Mon, Aug 31, 2020 at 11:53 PM Michael Voříšek - ČVUT FEL <
voris...@fel.cvut.cz> wrote:
> Optimizing foreach (array_keys($arr) as $k) is very important, not only
> because of memory, but because of speed when not all elements needs to
> be iterated, like:
>
> foreach (array_keys($arr) as $k) {
>
> if ($k some condition) {
>
> break;
>
> }
>
> }
>
Can an iterator be the answer? E.g.
foreach (new ArrayKeysIterator($arr) as $k) { ... }
--
Best regards,
Max Semenik
Re: [PHP-DEV] Possible RFC: UniqueInterface that throws exception at refcount > 1
On Sun, Jul 12, 2020 at 12:47 AM Olle Härstedt wrote: > You're misunderstanding. :) Yes, it should be shared, but not with the > same access level as the owner. If a dependent class closes the > connection it will cause spooky-action-at-a-distance somewhere else in > the program. Sorry, it's related to refcount as ownership checking and > not to throwing exception at refcount > 1. If your class doesn't know whether it created its connection or it was passed to it, it's badly designed. Not only would that mix concerns (making DB requests and managing connections), it would also be hard to test and hard to keep in the programmer's head. Use dependency injection to avoid that. I'm not convinced by this example. You can't use ownership as a protection against code doing something stupid. Imagine for a second you've prevented non-owners from closing your connection. Will that also prevent non-owners from dropping your database? What about them messing with your connection object's properties? Language features can only prevent developers from making accidental mistakes. Bad code is not an accidental mistake. -- Best regards, Max Semenik
Re: [PHP-DEV] Possible RFC: UniqueInterface that throws exception at refcount > 1
On Sat, Jul 11, 2020 at 5:32 PM tyson andre wrote: > This is something that makes more sense in compiled languages like rust > that can enforce uniqueness at compile time, > and the dynamic nature of php makes that less practical. > Also, crucially, Rust has language features that require a programmer to specify whether each variable is mutable or not. Without it, Rust's borrow checker wouldn't be possible. PHP has nothing like it, and introducing it at this stage would be prohibitively hard. -- Best regards, Max Semenik
Re: [PHP-DEV] [RFC] Property write visibility
On Mon, Jun 29, 2020 at 12:42 PM André Rømcke wrote: > This enables readonly, write-only and immutable like semantics for PHP's > properties. > I agree that there is a use case for it, however I don't think the proposed syntax `public:private` is intuitive. Maybe we can come up with something better? -- Best regards, Max Semenik
Re: [PHP-DEV] About the use of the terms master/slave and blacklist, proposal to replace.
пн, 15 июн. 2020 г., 19:15 Daniel Rodrigues Lima < danielrodrigues...@hotmail.com>: > But i believe that changing retrograde terminologies that refer to bad > feelings, > doesn't put us anywhere politically. > > > It's not about sides, it's about people, and our community is made up of > people. > The word "master" has 18 meanings in English, according to https://en.m.wiktionary.org/wiki/master - do you propose to outlaw those 17 of them that have nothing to do with slavery, too? What about master's degree, for example? >
Re: [PHP-DEV] Refactoring run-tests.php
On Fri, Jun 5, 2020 at 7:52 PM Sara Golemon wrote: > This is a perennial topic and I don't want to discourage you,BUT... > run-tests.php has a disturbing number of modes and edgecases, and the > preference has traditionally been for small movements which are easily > understandable individually. > That's why it's being done in a separate repository and every commit is tested to work. But yeah, once I get around to adding tests, suggestions of more things to test for will be appreciated. On Fri, Jun 5, 2020 at 8:04 PM Nikita Popov wrote: > Happy to accept run-tests refactorings in general (there is a lot of > global state to eradicate!), but please keep it single-file. We definitely > need it single-file for distribution purposes, and I don't particularly > want to have a "run-tests build system" for what I perceive to be little > benefit. > Once I add tests, it will just not be a single-file project anymore. > I'm not sure why PHP developers in particular seem to be so hung up about > this issue, but: There really is no need to split every class into a > separate file. This is how we develop in non-PHP, non-Java languages > (C/C++/Rust/...) all the time. > Because PHP taught them to: can't have a serious project without the autoloader, can't have a sane autoloader without per-class files (PSR-4 is as it is not due to its developers' preferences, but because it was the most reasonable thing to do). If only there was a way for classes to be automatically and seamlessly located from PHP core itself... My split into multiple files wasn't dogmatic, but purely pragmatic: a 3722 line file is too big for my liking (as in, it's too hard to find my way through it, even if the code is organized neatly into classes), and the number of lines will only grow. Also, it's way easier to have one tab per class. =) -- Best regards, Max Semenik
[PHP-DEV] Refactoring run-tests.php
I was thinking about making some improvements to our venerable test runner, however I wasn't feeling confident about improving the present code base. Instead, I decided to attempt to refactor it. Here's my work in progress: https://github.com/MaxSem/run-tests It requires Composer only for development, and has a script to make a single-file distribution, functionally identical to what we presently have. When it comes to integration with php-src, it could be moved to a subdirectory there or be kept in a separate repository and be used to generate a new run-tests.php whenever needed. Is there interest in this, should I continue? Any suggestions? -- Best regards, Max Semenik
Re: [PHP-DEV] RFC: Error backtraces
Thanks for your input! On Sat, May 30, 2020 at 8:36 PM Dan Ackroyd wrote: > For my own code, I convert all non-silenced errors and warnings into > an exception through the error handler*. That works pretty well, but > has one big downside - it only throws one type of exception. > > I wrote some words about what we could do: > https://gist.github.com/Danack/6b5a86414ab9e9d9ac7e0a906216f1c5 > > The TL:DR of that is, we could add specific exceptions that should be > thrown if the error handler setup by the user decided to throw an > exception. I would be interested in hearing if that idea achieves the > benefits you're trying to get, in a less controversial way. > Your solution requires programmers to write code supporting this kind of workflow, while I'm interested in providing useful information in all cases, even for legacy apps. > This has security implications as it would be possible for app secrets > to be included in the error message. That is less of a problem for > exceptions as you can write your own code for logging exceptions that > doesn't expose the variables if you don't want them exposed. > That's why I propose an INI setting controlling this behavior. > "..., traces are always generated for exceptions" > That depends on what callback function has been set for > 'set_exception_handler'. >From my reading of the code, backtraces are generated on object creation, in zend_default_exception_new_ex(). > Alsomaybe use more formal language for > RFCs. Even minor swear words should be avoided imo. > Sorry, didn't realize the word is, uh, "informal". > "error_get_last() output will have another element added to it if a > trace is available:" > > I strongly suspect that is a very bad idea. As the variables in the > stack trace are kept alive while that stack trace is kept alive, that > means the lifetime of those variables would depend on how long until > another error occurs. > As shown in the example output, traces are saved as string, so no implications to lifetime. > "In the current proposed implementation, a new error flag > E_UNHANDLED_EXCEPTION is introduced," > > The RFC doesn't say what this is meant to do precisely.but my gut > instinct doesn't like it. Clarified this with a link to the code: I needed it to avoid outputting the trace twice in some cases. > * an error handler that converts all unsilenced errors that we care > about into an exception > > function standardErrorHandler($errorNumber, $errorMessage, $errorFile, > $errorLine): bool > [snip] The problem with this is that it doesn't get called on fatal errors, i.e. you can't get traces for the most serious problems. On Sun, May 31, 2020 at 4:47 PM Nikita Popov wrote: > I'm concerned about the performance implications of this change. Backtrace > gathering is quite expensive and doing this for every diagnostic will have > a large performance impact if there are many of them. This is okay if your > code is intended to be diagnostics clean, but unfortunately this is not a > given. If you generate 10k deprecation warnings during a request, you're > definitely going to feel those backtraces. > INI setting should take care of this. If your code is crap, don't flip it on. > It is already possible to get a backtrace for all non-fatal diagnostics > through a custom error handler, which allows you to control whether you > want to collect a backtrace for a particular error. As such, I would > recommend to limit this functionality to fatal errors only, where such a > possibility does not currently exist. Additionally fatal errors also > naturally limit the performance impact, because there can (approximately) > be only one fatal error per request. > I guess having this only for fatals is better than nothing, however since this functionality is optional, I don't see leaks via traces as a serious problem. Backtraces are disabled by default in code and php.ini-production, so it's safe by default. On Tue, Jun 2, 2020 at 1:29 PM Peter Stalman wrote: > Isn't this something that is handled fairly well by xdebug already? Yes, but most people don't run xdebug in production. Also, it's not part of PHP core and thus some people might not have it in their hosting environment. Having basic diagnostics seems to me like a good thing to have in PHP proper. --- I've updated the RFC: clarified some parts and removed the voting question whether the configuration setting is needed, discussion clearly shows so. -- Best regards, Max Semenik
[PHP-DEV] RFC: Error backtraces
Hi, I'd like to present a new RFC for your consideration: https://wiki.php.net/rfc/error_backtraces In a nutshell, I'm proposing to give errors equal rights with exceptions and provide backtraces for them, too. -- Best regards, Max Semenik
[PHP-DEV] Re: [RFC] VOTE: Non-capturing catches
On Sun, May 10, 2020 at 11:34 AM Max Semenik wrote: > I've moved https://wiki.php.net/rfc/non-capturing_catches to voting. > Please state your opinions. This vote will will end on 2020-05-24 at 9:00 > UTC. > The vote has concluded now, and the RFC passed 48-1, thanks everyone participating! One last thing remaining is to get https://github.com/php/php-src/pull/5345 merged. However, I have no idea how to fix one last test failure - can someone help me, please? -- Best regards, Max Semenik
Re: [PHP-DEV] HTTP/1.1 by default in PHP 8.0
On Fri, May 22, 2020 at 12:54 AM Rowan Tommins wrote: > * PHP has a very simple HTTP client implementation, used by the "http:" > and "https:" stream wrappers, and also by extensions which make HTTP > requests, such as ext/soap Sorry, I'm an internals noob, but why does PHP implement this at all, instead of using an external library like cURL which is already fairly prominent in our ecosystem? -- Best regards, Max Semenik
Re: [PHP-DEV] Re: [RFC] Strict operators directive
On Sat, May 16, 2020 at 5:20 PM Mark Randall wrote: > IMHO we need to know what is happening with editions, as I think this > would be an ideal candidate for that rather than another declare On the other hand, a declare would allow a gradual upgrade path where people can use strict mode for new code and convert file after file at their own pace, taking their time to fix all the problems - while already taking advantage of new features where possible. -- Best regards, Max Semenik
Re: [PHP-DEV] [RFC] Guard statement
On Sat, May 16, 2020 at 12:14 PM Pavel Patapau wrote: > Hello everyone, > > I want to propose new syntax addition - guard statement, that executes > code only if expression equals false and must contain control-flow > changing code, and written a respective RFC Both your initial email and your RFC mention https://en.wikipedia.org/wiki/Guard_(computer_science) Note how no language mentioned in that article has this keyword, `guard`, or any special language construct, honestly. That's for a reason: the guard statement described in the article is a pattern, not a language construct. Also, consider that one can pronounce naturally "if foo [then] return bar" but "guard foo else return bar" doesn't make sense English. I would go further claim that in my opinion all current control structures in PHP are intuitively understandable to anyone familiar with programming but not the language. Can the same be said about `guard`? -- Best regards, Max Semenik
[PHP-DEV] [RFC] VOTE: Non-capturing catches
I've moved https://wiki.php.net/rfc/non-capturing_catches to voting. Please state your opinions. This vote will will end on 2020-05-24 at 9:00 UTC. -- Best regards, Max Semenik
[PHP-DEV] Re: [RFC] Non-capturing catches
Just a heads up, I'll put https://wiki.php.net/rfc/non-capturing_catches up for vote in a couple of days. -- Best regards, Max Semenik
Re: [PHP-DEV] [RFC] PHP Namespace Policy
On Tue, Apr 28, 2020 at 11:45 AM Rowan Tommins wrote: > One prefix doesn't make a trend. "PhpToken" is a different case - it's a > token of PHP source code, so the prefix isn't anything to do with avoiding > name collisions, it's a natural clarification. > There's also SPL, with classes like SplEnum, SplBool, etc. > To be honest, I'd be perfectly happy with the attributes RFC using the > class name "Attribute", just as we use "Iterator", "Closure", "Exception", > etc, etc. At which point the whole thing's a non-issue. > I hope it's not too late to change this before 8.0 is branched? -- Best regards, Max Semenik
Re: [PHP-DEV] Re: [RFC] PHP Namespace Policy
On Mon, Apr 27, 2020 at 11:26 AM Rowan Tommins wrote: > To me, the answer to that is quite simple: we have several hundred > functions, and several dozen classes and interfaces, which are not in such > a namespace; and we have millions of lines of code out in the world using > them. So either we need a strong rationale and a concrete plan to move all > of those into the namespace, or we need a consistent policy on what goes in > and what stays out. To me as an end-user, the ability to write readable code is as important as ability to write code that performs well and is well-tested. All these prefixes, like PhpAttribute being discussed right now, only decrease readability. I'd rather have to import \PHP\Attribute or use plain ol' \Attribute but no prefixes pretty please. I know they can be renamed locally via `use PhpFoo as Foo;` but that's a kludge. > It wouldn't make much sense, for instance, to have > PHP\str_contains but no plan to move str_replace. We don't have to mix namespaced and non-namespaced stuff within the same area, thus all str* functions should remain unnamespaced, and honestly I personally don't care if _functions_ are in \ or \PHP. I, however, would love if no new classes in PHP were prefixed. -- Best regards, Max Semenik
Re: [PHP-DEV] Any interest in a list type?
On Tue, Apr 21, 2020 at 10:00 PM Matthew Brown wrote: > Why "list" and not "vec" or similar? "list" is also a reserved word – I'm > imagining that you'd construct a list like > > $l = list["a", "b", "c"]; > "List" usually means linked list, "vector" would be much clearer and consistent with many other languages > I imagine such a "list" type would be a subtype of "array" – everywhere > that array was accepted, a list would be also, and it would have the same > copy-on-write behaviour. > > If people are interested in having that type, there's a question of what to > do with > > $some_list["a"] = 5; > > Would you convert the $some_list to an array, or throw an exception? > Converting to an array would seem the more PHP-like thing to do. > > Similarly, the behaviour of > > $some_list[$key_out_of_current_range] = 5 > > would be a matter of debate too – would that turn $some_list into an array, > or would it fill up any preceding entries in the array with null? > I personally would prefer as little implicit magic as possible. Just throw exceptions instead of allowing people to accidentally shoot themselves on the foot. What other questions are there? Is a "list" type even a good fit for PHP, > given most of its users seem pretty content with the current > swiss-army-knife array type? If we're to dream about some bright distant future of data structures, my dream would be to have a set of structures that make their big O behavior clear, à la C++ STL or many other languages' standard libraries. Some of them are already present in SPL, but notably not what you're proposing. Additionally, it would be wonderful to have generic versions, e.g. List would not just accept only ints, but would store them internally as zend_long, avoiding the overhead of zvals. > -- Best regards, Max Semenik
[PHP-DEV] [RFC] Non-capturing catches
Hiya, I'd like to present a new RFC for your consideration:
https://wiki.php.net/rfc/non-capturing_catches
Briefly, I want to be able to do the following:
try {
foo();
catch (SomeExceptionClass) {
bar();
}
Please share your thoughts! :)
--
Best regards,
Max Semenik
[PHP-DEV] RFC karma request
Hi, can I get RFC karma please? I'd like to write a RFC related to https://github.com/php/php-src/pull/5345 My account name is maxsem. -- Best regards, Max Semenik
