Comments Inline > 1) What we know and have been told is that PHP's signature > checking is governed by Liskov Substitution Principle. There are > many references to this in the list.
Except that signature checking is not needed for LSP to function. You can write all of your code using duck typing without interfaces and abide by LSP 100%. In fact, you can do things like override a function with a signature of foo($bar, $baz) with one of foo(), and STILL have it be LSP compliant due to the dynamic ways PHP handles arguments. So LSP may be a motivator, but ti's not the reason. What could be a reason is to enable Design-By-Contract style development where the interface is the defined contract. Now since PHP doesn't support dynamic introspection of the method at run-time, the signature is the only way of determining if the method abides by the contract. > 2) "Abstract Constructors" do not exist in any other language, for all > intents and purposes, it's something we've invented: True, however in most other language constructors are not actual methods, but a pseudo method on the object that can't be called explicitly aside form `new` (obviously not true for all, but most of the big ones). Additionally, PHP is quite different from a fair bit of other languages in that you can do things like `new $class()`. Java and C# don't allow this. So to them, it's not an LSP violation or even necessary to have it abstract since you **know** the subtype your instantiating. However, in PHP that's not true. You can do variable-class-names. So that eliminates the assertion that you **know** the subtype your instantiating. You don't, and you can't. But you can check the interface on the class name in the variable (which is what I did in that library I posted before). So by specifying the constructor as abstract/interface is one way of adding safety when you accept a class name and do dynamic instantiation... > http://www.google.com/search?&q=%22abstract+constructor%22 > > That's fine, so now the question is, how does this thing we've invented play > in with our current implementation of a class based object model and how > does it meet developer preexisting expectations? There are two ways to see it. Either constructors are really just a method that's called by the engine, or they are not a method and are special "blocks" which are not callable in userland. However, since I can legally call `$obj->__construct()`, I think it's pretty safe to say that it's considered a real method in PHP. And real methods are specifiable in abstract/interfaces. So really we didn't invent anything at all. The "invention" is that the constructor is a method (with all the caveats that apply)... > 3) In places that have no formal expectation and understanding in other > programming languages, we've OFTEN favored *looseness over strictness* > > Even you Pierre, once promoted "looseness" > http://news.php.net/php.internals/25089 (Pierre) Well, looseness over strictness unless strictness is specified. Look at the class based type hints. That's strict. Interfaces and signature checking are absolutely strict. Considering that the use is optional, and the construct that's using it is normally associated with strictness that it's ok that the constructor check is strict... Again, I'm not arguing the design decision of putting a constructor in an interface. I'm talking about what would be expected if you did, or more specifically if you're allowed to... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
