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."
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 anE_STRICTand 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 tothe 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."
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
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 anE_STRICTand 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."