Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82739
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <21.3B.06835.703F0E45@pb1.pair.com>
To: internals@lists.php.net
References: <CAJ26g5Swk1z2W-kR6FG77M1bPJPQjVUihd13-27ngwHK7A8+cA@mail.gmail.com>
In-Reply-To: <CAJ26g5Swk1z2W-kR6FG77M1bPJPQjVUihd13-27ngwHK7A8+cA@mail.gmail.com>
Date: Sun, 15 Feb 2015 20:26:54 +0100
Lines: 1
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="utf-8";
	reply-type=original
Content-Transfer-Encoding: 8bit
Importance: Normal
Subject: Re: A modest proposal: __contructStatic
From: bensor987@neuf.fr ("Benoit Schildnecht")

Hi Patrick,

I don't think it should be implemented. If you are calling a static method
like a non-static method, your code has a problem. I think it would do
more harm than good. Not only for the code comprehension and logic,
but also for the skills of the people who make this mistake.

But I find this __constructStatic() method kinda appealing. I'm writing my
code so I don't need one, but I may use it if it is implemented.

Regards,
Benoit.

"Patrick Schaaf"  a écrit dans le message de groupe de discussion :

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