# interface method visibility. - Thread: https://externals.io/message/20064 - Original archive: https://news-web.php.net/php.internals/20064 - Started by Jochem Maas on 2005-11-16T15:24:39+00:00 - Messages: 4 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #20064 — Jochem Maas — 2005-11-16T15:24:39+00:00 URL: https://externals.io/message/20064#20064 why does the engine care about the visibility of interface methods I declare? I understand the argument that interface methods only have 'meaning' when applied as public methods of objects - but thats rather academic and personally I can think of useful ways to abuse interfaces using protected methods at the very least why am I not allowed to do this just because someone decided that its not correct? and given that I can implement a non-static method without using $this or any other symbol/code related to the instantiated object (effectively creating a static method) which I can call using static notation why not allow static interface methods? also I noticed that using the keyword 'abstract' with a interface method declaration is all of a sudden (5.1RC5dev) causing a fatal error where before (5.0.2 - 5.0.4) no error what so ever. If 'static', 'protected', 'private' are not allowed with interfaces (very unpragmatic imho) then why the fatal errors? why not an `E_STRICT` and just ignore those declaration... especially because not declaring a method static and leaving off the visibility leaves you with a method that is non-static and public - exactly what an interface 'requires'. rgds, Jochem ---- some might ask why I am asking - well the motive is quite simple: "I try to stay on top of php developments, trying out to the best of my abilities new features whenever I see an opportunity. partly for fun, partly to be able to encourage/help others to step up to the php5 plate. lately I _feel_ I am being punished more and more for trying to keep abreast due to BC breaks (some of which, I realise, are very much required) and more annoyingly abitrary changes in behaviour." --- ## #20069 — Andi Gutmans — 2005-11-16T17:34:18+00:00 URL: https://externals.io/message/20064#20069 · In reply to: #20064 Please read the archives where discussions took place. As you stated it would be "abusing" the notion of what interfaces are. Take a look at abstract classes. That might help you. Andi At 07:24 AM 11/16/2005, Jochem Maas wrote: >why does the engine care about the visibility of interface methods I declare? >I understand the argument that interface methods only have 'meaning' >when applied >as public methods of objects - but thats rather academic and personally I can >think of useful ways to abuse interfaces using protected methods at >the very least >why am I not allowed to do this just because someone decided that >its not correct? > >and given that I can implement a non-static method without using >$this or any other symbol/code >related to the instantiated object (effectively creating a static >method) which I can >call using static notation why not allow static interface methods? > >also I noticed that using the keyword 'abstract' with a interface >method declaration >is all of a sudden (5.1RC5dev) causing a fatal error where before >(5.0.2 - 5.0.4) >no error what so ever. > >If 'static', 'protected', 'private' are not allowed with interfaces >(very unpragmatic imho) >then why the fatal errors? why not an `E_STRICT` and just ignore those >declaration... especially >because not declaring a method static and leaving off the visibility >leaves you with a >method that is non-static and public - exactly what an interface 'requires'. > >rgds, >Jochem > >---- > >some might ask why I am asking - well the motive is quite simple: > > "I try to stay on top of php developments, trying out to > the best of my > abilities new features whenever I see an opportunity. > partly for fun, partly > to be able to encourage/help others to step up to the php5 > plate. lately I > _feel_ I am being punished more and more for trying to keep > abreast due to BC breaks > (some of which, I realise, are very much required) and more > annoyingly abitrary > changes in behaviour." --- ## #20074 — Jochem Maas — 2005-11-16T18:51:50+00:00 URL: https://externals.io/message/20064#20074 · In reply to: #20069 Andi Gutmans wrote: > Please read the archives where discussions took place. > As you stated it would be "abusing" the notion of what interfaces ar > Take a look at abstract classes. That might help you. 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 --- ## #20075 — Wez Furlong — 2005-11-16T18:54:54+00:00 URL: https://externals.io/message/20064#20075 · In reply to: #20064 An interface is a public contract that describes the behaviour of an object. If you're not using interfaces in that way, you're doing something fundamentally wrong. --Wez > why does the engine care about the visibility of interface methods I declare? > I understand the argument that interface methods only have 'meaning' when applied > as public methods of objects - but thats rather academic and personally I can > think of useful ways to abuse interfaces using protected methods at the very least > why am I not allowed to do this just because someone decided that its not correct? > > and given that I can implement a non-static method without using $this or any other symbol/code > related to the instantiated object (effectively creating a static method) which I can > call using static notation why not allow static interface methods? > > also I noticed that using the keyword 'abstract' with a interface method declaration > is all of a sudden (5.1RC5dev) causing a fatal error where before (5.0.2 - 5.0.4) > no error what so ever. > > If 'static', 'protected', 'private' are not allowed with interfaces (very unpragmatic imho) > then why the fatal errors? why not an `E_STRICT` and just ignore those declaration... especially > because not declaring a method static and leaving off the visibility leaves you with a > method that is non-static and public - exactly what an interface 'requires'. > > rgds, > Jochem > > ---- > > some might ask why I am asking - well the motive is quite simple: > > "I try to stay on top of php developments, trying out to the best of my > abilities new features whenever I see an opportunity. partly for fun, partly > to be able to encourage/help others to step up to the php5 plate. lately I > _feel_ I am being punished more and more for trying to keep abreast due to BC breaks > (some of which, I realise, are very much required) and more annoyingly abitrary > changes in behaviour."