Hello Internals, seeing the static calling of instance methods being discussed again, I want to ask whether the following idea would maybe have a chance?
In our codebase we have one set of classes where it was very useful to be able to call the same methods both statically and nonstatically: a set of wrapper classes over phpredis where subclasses "know" which set of redis servers to talk to (plus other config like retry strategies and timeouts). In most cases calling code does not need to be concerned with these details and just calls methods like red_global::get() or red_local::put(). By neccessity the implementation of this class set, must make use of both __call() and __callStatic() magic methods, with both then dispatching to a delegate phpredis instance, and in the case of __callStatic(), making up-front a singleton like "new self" once. For a set of additional helper methods (not present on the underlying phpredis) I additionally have a special mapping array of real method names to internal implementation names. A similar approach can be useful for database connection abstraction classes. Now for the idea how this might be made much more simple: onviously in the light of the "static call to method using $this" warning/detection, PHP already knows exactly where it hits such a static call to an instance method. At that point, check whether the class has a "static instance" already. When it has one, call the method with $this being that "static instance". Otherwise, create the static instance, calling a new magick method named __constructStatic() to initialize it. Only classes that have such a __constructStatic() method, would be treated that way. For other classes the "static call to instance method" case would be an error as before/discussed. This approach would clearly simplify my redis wrapper classes, maybe even enable them to be proper subclasses of phpredis (saving an indirection to a $this->delegate object). All the special dispatch and __callStatic instantiation logic could go away. The cost would be one internal pointer (to the "static instance" object) per class, a kind of hidden "static protected" property, and only needed when the class (or one of its superclasses) _has_ a __constructStatic method in the first place. What do you all think? Interesting? Somebody hot for helping with impementation? Then I'd make an RFC of it. best regards Patrick
