that’s strange. I left a comment on “The Secrets of PHP” this morning. Now its gone. Did you delete it? Its not really good style to “control” the comments on a blog…

Cheers,
Bastian.

however…

I want to add one point. a point which is important for me as a teamleader and project manager in software development: PHP, in my eyes, becomes more unuseful the larger the project (not measured in lines of code but in aspects an application or enterprise modell has) and the amount of people working together in a team on that project. php does not support effective teamwork…. interface design without defined return and parameter types makes it hard to reuse and extend things such as it is possible in… say… java. the boundaries of java itself and the boundaries of interfaces and the usage of modules in java reduce the risk to fail and thus the time trying to integrate with other parts of an application.
other missing features of php are effective namespaces and packaging (deployment) of applications. one example: you are working on an enterprise project which works with direct database interaction using some kind of DBConnection Class. Good enough - PHP is a nice language to abstracterize things that way. But over time the database model becomes more complex and demands a business layer which maps the database structure to an object oriented model. here comes the problem. in other languages you easily would develop this layer independently from the rest of the application in a single project. as soon as the model works in some test applications the subteam would deploy the model package (in java as a jar file) (including sokme configuration files) and providing it under a specific version to the subteam which develops the rest of the application. they would now implement some integration and mapping facilities against the interface of the included model package. The other team (the model team) could begin to improve or broaden the model in parallel without touching any other part of the application. they dont even have the possibility to touch and modify other parts since their project is independent from the rest. however, as soon as they could publish a newer and better version of the model project they will buzz the dev team and they will include the newer version to the classpath. thats it.

in php such things are possible, of course, but you must force yourself to do so. you must force yourself not to choose the line of the least resistence. forcing yourself is easy. forcing 20 developers in a team is almost unpossible. that is my biggest problem with php.

So, for example, in a context where MooingGrassEater’s moo() method is visible, it would be considered to “implement” Cow. But from a different context where moo() is not visible, it wouldn’t be considered to “implement” Cow.

Would only the method name be used for comparison? What about differing parameter pass semantics (value vs ref), type hints, default values etc…?

But only drawbacks are “PHP is not using in big enterprise”

Alan - optional interfaces would be a nice idea too, but different one

Now with that out of the way, to the exception thing. You can do that easily with __call, but I see no reason why - throwing exceptions left in right is not really the style I’d like.

<?php
interface Mooer {
function moo();
}

class Cow implements Mooer {
function moo() {
echo ‘moo!’;
}
}

var_dump(new Cow() instanceof Mooer); // bool(true)

I never try this function, cause i have migrate to python now. But I will be happy if u do some kind of return