interface method visibility.

Andi Gutmans wrote:

Andi, I read pretty much everything but the account requests on internals (and have done since php5 was in beta), I am aware of the discussion you refer to and I understand the logic regard how interfaces should be used (i.e. what they were made for, at the very least in the eyes of those who made them in this case). I put 'abuse' in quotes because there is no one definitive answer to software design - and my experience is people disagree wildly on what is right and wrong. my complaint is that alot of the 'small' changes that have been happening lately that are sold as improvements with regard to better software design, improved development feedback (in order to catch bugs before they bit you, etc) but they don't always stand up to the sales pitch IMO. stating 'abstract' shouldn't be set on a method declared in an interface definition is one thing but making it a fatal error to do so is another - baring in mind the context that it used to work, and as far as I can see does no harm (i.e. the engine can just ignore it). the E_FATAL forces the coder to the change the code on the spot ... an E_STRICT would give the coder a hint on how to write better/correct code but does not force him to do something about it. another example is array_merge() whose behaviour is now inconsistent with how one can use an array or null interchangably elsewhere. more worrying is the seemingly very real posibility that php functions will soon be auto casting their arguments in a different way to explicit casting (and auto-casting within expressions?). I have spent alot of time studying and learning how the casting works in php (100,000's of people can probably say the same) - all that is put in jeopardy for the sake of some purist dream... whether "123abc" shouldn't cast to integer "123" or whether is should doesn't interested me - the fact that it does I consider a plus point, php's autocasting rocks - what I do find important is that it keeps working as it does. I have given a couple of examples of break/changes that I feel are counter-productive, goes against the practical/pragmatic ideal that php (I believe) was built upon, and possibly most importantly alienate (lesser) coders and damages php's reputation. The whole situation is compounded by the fact that [mainly] quite severe (in terms of affect on php users) changes _had_ to be made to the engine recently that caused BC break related to references. which is a case where there was a very strong argument (the only critism might be that the argument was not conveyed to php userland strongly enough). At any rate php has had to undergo some changes that really were required and it was a bitter pill for most (Derick R. I recall spent alot of time getting his EZsystem to work with the fixed reference stuff.), from a marketing perspective following a necessary bitter pill with a stack of bitter pills that are not strictly necessary in quick sucession is bad tactics. so my whole gripe lies in the arena of consistently and the aparently increasing lean toward purism for its own sake (which to me is not the same as improving or fixing something because it really needs/deserves it) rather than towards what may or may not be the academically correct implementation of a feature. or are we witnessing php's slow but sure departure from its roots in order to preen it for enterprise use, leaving its major userbase stuck with php4 and looking for a new home? thanks very much for your time, rgds, Jochem