Am 15.02.2015 23:34 schrieb "Rowan Collins" <rowan.coll...@gmail.com>:
>
>> You can surely see how this is more readable / easier to write:
>>
>> $value = MyRedir::get($key);
>>
> Actually, no, I find that harder to read accurately - there is no clue
there that there is actually a singleton under the hood, and that this is
actually an instance method in disguise.
Fair enough. You judge readabilidy by "an unaccustomed reader can grasp
(better or worse) what lies behind this construct". I have a different
focus, as I'm just a herder of a small group of internal developers.
>> > The nice thing about an explicit Singleton is you can migrate to
Dependency Injection (call "$redis = MyRedis::singleton()" and start
passing the instance around,
>>
>> I _can_ do that with my redis class, where I need it, by calling a
method MyRedis::link() which just returns $this. But the places where I
need that are rare.
>>
> You may be able to do it with your current implementation, but how do you
propose to do it with an invisible singleton property implicitly created by
__constructStatic?
Without any caller side change, calling this already existing instance
method:
public function link() { return $this; }
> OK, but you need a new subclass every time, not just a new method, or new
parameter; that limits your options. For instance, you can't dynamically
create instances based on configuration of a reusable library, which could
be as simple as adding an optional parameter to a standard Singleton:
Nothing would stop me from writing and using such a subclass, while having
fixed (in code) configuration sibling classes. Or add such a
fixed-config-singleton class method to the base class to add that to the
whole hierarchy. I don't have the need. But I could.
> Any function that already uses the "$redis = MyRedis::inst();" pattern
can then quickly be changed to "$redis = MyRedis::inst('volatile');" and
continue to work fine.
Or, in my case, s/MyRedis::/MyRedisReg::inst('volatile')->/g. Piece of cake.
> "Extend" was perhaps not the word I should have chosen; I was thinking of
"extending the use of the class beyond the current coding pattern". By
implementing one specific use case as a magic method, you make it harder to
do anything other than that one use case; or, you end up creating a whole
set of magic methods and features, which are then no easier than just
implementing the whole thing by hand.
Nothing of that. By base class is fully flexible! It even throws an
exception when a coder tries to singleton-like use it itself - it's just
the concrete subclasses that can be used that way.
I consciously chose this nonextensibility. Of course this is (for the given
fanout of different redis servers) nothing that a public facing library
would use! I'm watching over a four man coder show writing a single web
site's code not indented for public consumption. And there, such things not
only make sense, they happen all over the place.
Anyway, I'm pretty sure that singleton subclasses are useful in various
other one-of-a-few-specializations cases for completely different uses, and
there the patterrn might just make sense, too.
I certainly understand your criticism, from a point of view of more
publically consumable codebases / libraries. Thanks for your feedback.
best regards
Patrick
