2015-02-15 21:04 GMT+02:00 Patrick Schaaf <p...@bof.de>: > 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
+1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
