Hi,
As I see it, adapters not only serve declaration purpose, they also can
adapt the method and param names and even alter or tune the execution flow.
Imagine this simple case:
You have a protocol Duck with method walk() with few concrete
implementations. Later you have another instance of Duck, but its
corresponding method is called walkAround(). What would be the sane pattern
to solve this problem? Should we now implement an adapter for the protocol?
I think if we're interested in simplification, there should be a more
flexible way to create adapters instead, maybe with method/param mapping
abilities. E.g.:
class Duffy { function walkAround($speed, $distance) {} }
interface Duck { function walk($distance, $speed); }
adapter DuffyDuck extends Duffy implements Duck {
function walk($distance, $speed) as walkAround($speed, $distance);
}
or in a simpler case -
class Donald { function walk($distance, $speed); }
adapter DonaldDuck extends Donald implements Duck {}
It solves same problem as the proposal, but in explicit, maintainable and
analyzable way, IMHO.
On Wed, Jun 26, 2013 at 5:51 AM, Nikita Nefedov <inefe...@gmail.com> wrote:
> Hi,
>
>
> On Wed, 26 Jun 2013 02:57:46 +0400, Stas Malyshev <smalys...@sugarcrm.com>
> wrote:
>
> That means all you really need is to call method named "get", regardless
>> of what it actually does. Usually the code doesn't work this way - you
>> expect something to actually happen if you call get(), something
>> specific. Interface ensures whoever wrote that object acknowledged that
>> this is what he wants too.
>>
>
> But you (as a library dev) still have interfaces. You still use them.
>
> This discussion got really big in a short period of time, but we all know
> all this change does is gives us an ability to not write additional code.
> Some people already stated it - you just won't need to create adapters and
> it's cool.
> There's a lot of cases where you need to wire to different libraries and
> for that matter you create THIRD library and call it something like
> %lib1-name%%lib2-name%Adapter where you, in the best case, should create
> classes that inherit from some lib1's or lib2's classes (and just add
> "implements Lib2Interface"), or if there's some static methods - you are
> forced to create decorator which implements needed interfaces - and that is
> what will give a far more overhead than some runtime engine-level checks.
>
> What about static analysis, it just lays on YOUR shoulders, if you so want
> static analysis to work properly you just write code which implements
> interfaces. But if it's fine for you, then it's fine, it's easy.
>
> PS sorry for caps in some places
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
