Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82741
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.169 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAJ26g5Swk1z2W-kR6FG77M1bPJPQjVUihd13-27ngwHK7A8+cA@mail.gmail.com>
References: <CAJ26g5Swk1z2W-kR6FG77M1bPJPQjVUihd13-27ngwHK7A8+cA@mail.gmail.com>
Date: Sun, 15 Feb 2015 21:30:59 +0200
Message-ID: <CALW=WEDWS1o67vbiz6g=hns-qknP7_uJhen1fRGs2DG=75sFww@mail.gmail.com>
To: Patrick Schaaf <php@bof.de>
Cc: internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] A modest proposal: __contructStatic
From: ua.san.alex@gmail.com ("S.A.N")

2015-02-15 21:04 GMT+02:00 Patrick Schaaf <php@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