Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82737
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain bof.de designates 80.242.145.70 as permitted sender)
MIME-Version: 1.0
Date: Sun, 15 Feb 2015 20:04:09 +0100
Message-ID: <CAJ26g5Swk1z2W-kR6FG77M1bPJPQjVUihd13-27ngwHK7A8+cA@mail.gmail.com>
To: internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c129947416d4050f252235
Subject: A modest proposal: __contructStatic
From: php@bof.de (Patrick Schaaf)

--001a11c129947416d4050f252235
Content-Type: text/plain; charset=UTF-8

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

--001a11c129947416d4050f252235--