Thanks for all of your guys' comments on this. Ultimately I see Zeev's insight of PHP not having a strong type definition totally accurate. Even if we did have a mechanism to make sure that a class defined certain functions, we could not readily see if these functions did what we wanted, bringing us to the same problem.
The delegation construct looks promising for having a means of multiple inheretence. Ben Zeev Suraski wrote: > At 09:30 21/08/2002, Ben Dischinger wrote: > >> You don't quite get the same functionality from extending a class as you >> would from implementing an interface. If I'm extending temperature what >> keeps me as a user from not overriding any of those functions? Or >> what if I >> want to extend a different class but still define my class as having >> those >> functions found in temperature? Having interfaces is a nice way to >> skirt >> the issue of not having multiple inheritance built into the language. > > > Interfaces, IMHO, simply do not fit the spirit of PHP. PHP is > extremely loose about what it 'demands' from the programmer. You > don't have types, you don't have to declare variables. But suddenly, > we would have a construct that 'requires' you to implement certain > functions? Ok fine, so you would have to implement a certain set of > functions, but given the loose typing, what does that buy you anyway? > You can't force him to return what you expect, or even deal with the > arguments you send him according to their intended type. > > I don't see interfaces as something which makes too much sense in the > context of PHP, and considering the added complexity of adding such a > new feature, I'm against it. Typically, the argument is between > single inheritance with interfaces, and multiple inheritance. We went > for a multiple-inheritancish approach with delegation, and I don't > think we should overcomplicate it with interfaces. > > Zeev > -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
