Hi! > See my reply to Laruence, it's not more expensive...
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). > 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? > 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? > 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? > 1. Protocols are intended to resolve a minimal interface. You should > hint against the smallest possible area that your particular > method/class needs. If your function only calls a single method, then > the protocol hint interface should have only that single method (within > reason at least). If you need one method, why not check for one method? Would you create interface for any combination of methods you might call and add new ones as you change the APIs or add functionality? That'd be the real interface hell... > 2. Yes, it does limit the usefulness of static analysis. But then again, > the vast majority of the PHP language (especially the type system) > prevents that already. Considering that the PHP philosophy is that "if Not true, any IDE worth its bytes can and does easily alert you when you forget to implement certain method in a class, given interface declaration. If you change the interface, it is easy to locate every class that needs amending. Even without IDE's help, loading these classes would immediately error out, thus alerting you on the problem, so even minimal coverage test system would easily deal with it. With undeclared interfaces, on the other hand, the first time you know about it is when you use that particular class in a particular place that new function is actually used. So unless you have 100% coverage, that'd be in production. > it looks like a scalar, it's a string", wouldn't protocols be arguably > more along the lines of "the php way" than the current object system? Not really, because scalars are quite easily convertible (arrays excluded - Array conversion should have been an error from the start) with meaningful results. Converting DOMXPath into PDO_ODBC doesn't really produce a meaningful result, even if both may have method called "query". -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
