Bug #75474 [Opn->Csd]: function scope static variables are not bound to a unique function

From: Date: Thu, 18 Feb 2021 10:40:03 +0000
Subject: Bug #75474 [Opn->Csd]: function scope static variables are not bound to a unique function
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-232234@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=75474&edit=1 ID: 75474 Updated by: nikic@php.net Reported by: nobots dot nospam at example dot org Summary: function scope static variables are not bound to a unique function -Status: Open +Status: Closed Type: Bug Package: Scripting Engine problem PHP Version: Irrelevant Block user comment: N Private report: N New Comment: Automatic comment on behalf of nikita.ppv@gmail.com Revision: http://git.php.net/?p=php-src.git;a=commit;h=6b0f14fe3b08be05340c6a4ae03f4131f04d882a Log: Fixed bug #75474 Previous Comments: ------------------------------------------------------------------------ [2017-11-03 12:55:00] nikic@php.net @cmb: That case is something of a mess, which depends on the order in which you do things. Bob had a patch that normalized this (https://github.com/php/php-src/pull/1899), though it did not go anywhere... ------------------------------------------------------------------------ [2017-11-02 18:17:25] cmb@php.net > Static variables should be shared. I agree. But what about the current working of function statics in subclasses, e.g. <https://3v4l.org/4rICv>? ------------------------------------------------------------------------ [2017-11-02 10:58:17] nikic@php.net Static variables should be shared. It should not make a difference whether a callable is invoked directly or indirected through Closure::fromCallable(). The current behavior will also negatively interact with future plans for more first-class callable references based on closure objects. As for returning the same object, I don't think we're going to add such a guarantee. In any case, it should be part of a separate request, as it is unrelated to the static variable bug (which are due to internal state management, not which object is being used.) ------------------------------------------------------------------------ [2017-11-02 09:55:18] Wes dot example at example dot org yes you can document the incomplete functionality if you want, but it won't make the user experience any better comparing objects seems to me a very basic feature I don't really care about statics as I rarely use them, but again I doubt the current behavior is what people expect what's the point of Closure::fromCallable("foo") then? if I did function(...$a){ return foo(...$a); } I'd at least have the static variables working ------------------------------------------------------------------------ [2017-11-02 09:29:25] requinix@php.net > essentially Closure::fromCallable() and $RF->getClosure() should always return the same > Closure object I disagree. Both of them are documented to return "new" (Closure::fromCallable) or "dynamically created" (ReflectionFunction::getClosure) closures - copies of the original, not shallow references to it. And that implies copies of any static variables it may have, which is why the first fromCallable shows [0,1] instead of [1]. Regular functions and closures are two separate things: a function is not a closure, and a closure is not a function*. Creating a closure from a function is not like creating an alias or performing some sort of import (cf. traits in classes). How about we clarify the behavior in the documentation? * It's an object (\Closure) that behaves like a function, and is defined using syntax that resembles that of a function, but is not actually a function. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=75474 -- Edit this bug report at https://bugs.php.net/bug.php?id=75474&edit=1

« previous php.bugs (#232234) next »