Stas,
I don't see how you can see it's not - it does method matching on every
> call. It just doesn't make sense that doing something N times is faster
> than doing something 1 time. That may be true only if you load classes
> you don't ever need (no autoloader? why?) - but even in this case your
> model still has to load the class once the typing statement is
> encountered (actually, once it is compiled if inheritance is in place
> since you have to check it against inherited interface to see if the
> inheriting interface did not change it in incompatible way).
I'm not making things up. Look at the patch. Run it. It does not slow
things down.
It only does method matching on the first call. Every subsequent call
caches it. And let's try running the same benchmark with 1 iteration
(taking caching out of the picture):
Interface in 1.5974044799805E-5 seconds, 1.5974044799805E-5 seconds per run
Protocol in 1.4066696166992E-5 seconds, 1.4066696166992E-5 seconds per run
Native in 6.9141387939453E-6 seconds, 6.9141387939453E-6 seconds per run
It's **still** faster.
Want to dig through the code to see why? Go for it:
https://github.com/ircmaxell/php-src/compare/protocol_proof_of_concept
But I'm not making this up...
> > As far as "you can easily add implements", that ignores the relationship
> > where you may not own all of your code. I know I've been in many
> > situations where I've "just needed to add an interface" to a class,
> > except that I didn't own that class. Which led me to either drop the
> > type-hint entirely, or do some nasty work-around.
>
> If you don't control the code, how can you ensure it actually does what
> your contract requires it to do - and keeps doing it in the next
> version? If you can't ensure it - what these checks are worth? What
> exactly will you be checking and what value would you derive from these
> checks that would not be present otherwise?
So nobody should ever use libraries, because they can't be sure of that
code... So...
> > Why not?
> >
> > Seriously, why not?
>
> Because check that says "accept any object that has __call" doesn't seem
> very useful for me. What exactly is it checking?
It's checking that fatal method-not-defined erros won't be thrown...
And avoiding E_FATAL is quite significant...
> > This gets down to a deeper philosophy. Control when you need it, but
> > freedom where you don't. Not everyone is going to want to program like
> > this. But the point is that a lot of people do today, and why not offer
> > some engine level help to them...?
>
> We already have support in the engine for them. Typing in PHP is not
> mandatory, never was and I sincerely hope never will be. So you can pass
> any object anywhere. What exactly checking for __call adds there?
It gives the ability for a method to be defensive by preventing E_FATAL
errors. That's not adding something significant?
(as to the rest, I don't want to keep arguing the same rabbit hole over and
over. I've made my points, take them or leave them).
I agree the use-cases are slightly weak. This is a draft RFC. It's supposed
to help identify the areas where we can improve it. Help identify
use-cases. Help dig it out.
But right now, this discussion is completely counter-productive.
Anthony