AW: interface method visibility.

Matthias Pigulla 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?

Having anything else than "public" in an interface simply does not make
any sense - an interface serves as a contract to external clients. It
guarantees them that there will be a set of methods they can call on an
object instance. What should be the semantic meaning of non-public
elements in interfaces?

thats not my problem though is it - and I did mention that I already understand
what you you are now repeating.

I had a good reason to create an interface whose
methods were only relevant to the innards of a particular (rather large for my doing)
class hierarchy - I don't give a rats ass as to what you think the 'semantic meaning'
of that should be - it worked in the 5.0RC1, I understood what I was doing and
I was happy doing it. I certainly was not forcing you to do it too, so why
force me to rewrite/hack my code (sometimes you devs have to do this because I abuse
things like array_pop() ;-) but I don't feel that this is the case here at all).

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?

As to static interface methods - same as above. An interface is an
interface :), not an implementation. So you will never have methods
implemented in an interface. The interface just says "the class
implementing the interface has a method named xy() that you can call".

So how would you make the static call on the interface?
ISomewhat::someMethod()? Where should that be implemented? This is why
you always need an instance that implements the interface and you make a
"normal" call on this instance. PHP allows - as opposed to C# or Java
(IIRC) - to call static methods on instances.

right which meant in one particular case I had to create an object especially
to call the given method, very wasteful, pointless and the only good reason there
seems to be is some academic crud which you have reiterated here.

I think the fact that you can call nonstatic methods statically is BC
with "early days"; you don't want to do that in your code because it
will get you problems sooner or later. In "older" code you could not
mark methods as static, so the language could not check if a static call
is allowed. It simply permitted the call, not setting $this.

everything I mention here is related only to my experience
with php5 and up since Nov'03.

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.

I thought I would never write anything like that - but: What sense does
"abstract" make in an interface at all?

the point is it doesn't hurt you to let me do it. if it makes sense to
me but nobody else thats no reason not to allow it on grounds of principle
when it is clear that it has worked without problem.

You shouldn't have been writing "abstract" in an interface in the first
place. >:)

thank you very much - how enlightening. the engine can safely ignore the
'abstract' regardless at that point. no E_FATAL required.

besides semantically an interface is abstract as are the method declarations in it,
I am not allowed mark a method in an interface as 'abstract' but I'm not allowed
to give it a body either - notice a slight discrepancy?

or are you saying that the 'abstract' keyword in the declaration of an
interface method opens the doors for painful/impossible to debug
segfaults? if so I'll retract my opinion.

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...

As I understand it, E_STRICT is for complaining about stuff like "var"
that was ok with PHP4 but is discouraged in PHP5. But you are using PHP5
elements in a way that make no sense to the language, so it's simply an
error.

and as I understand it E_STRICT is for pedantic checking - i.e. check if every t
is crossed and every i dotted (so to speak) nothing perse to do with
php4 (or will E_STRICT be dropped when support for php4 code is dropped from the engine?)

anyway that was merely a suggestion - basically the E_FATAL is bogus imho.

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'.

You're explicitly requesting something that is not possible - an fatal
error is the only thing that can be the result.

if its not possible then I what flippin' universe have I been coding in
for the past 2 years??? the only thing making it 'not possible' is
self-imposed purism.

Matthias