# AW:  interface method visibility.

- Thread: https://externals.io/message/20083
- Original archive: https://news-web.php.net/php.internals/20083
- Started by Matthias Pigulla on 2005-11-16T22:54:45+00:00
- Messages: 1
- 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

---

## #20083 — Matthias Pigulla — 2005-11-16T22:54:45+00:00

URL: https://externals.io/message/20083#20083

Jochem,

the point with most of these issues is that there's no common
understanding of what things like protected or static interface members
mean; from an OO point of view, they make no sense, and I was only
trying to explain why.

Unless there is a common understanding what a certain language construct
means, every way of implementing it is pretty arbitrary. So not
implementing it at all is not "self-imposed purism".

> should be - it worked in the 5.0RC1, I understood what I was 
> doing and I was happy doing it.

If these things were legal with 5.0.0 (were they really? I dunno...),
one could argue wheter it's good practise to 'suddenly' make them
E_FATAL in a minor release. However, even if they ever worked, at best
it was undocumented (=random) behaviour.

> 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 don't get that should have worked otherwise, but if you want to let's
discuss this one off-list.

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

If a method does not access "$this", it can be used statically. So best
would be to have the "static" modifier in place to make things clear,
but that would require _you_ to add it to your pre-php5 'legacy' code. 

So, although "academically" not correct, the engine still permits it -
simply because it did so in the past in an agreed-on manner. With
 `E_STRICT` it will addidionally tell you that as of PHP5 you have a
keyword to get it "right".

> > […]
> 
> 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.

"Worked without problem" is not necessarily a good argument for such
things.

However, I just found that "abstract" was also once legal in Java
(http://java.sun.com/docs/books/tutorial/java/interpack/interfaceDef.htm
l, note at the bottom). They removed it because it makes no sense
(interfaces are abstract by nature).

Now I know that this is by no means a better argument ;), but maybe a
notice instead of fatal would be enough?

> > […]
> 
> 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?)

I am not really familiar with engine internals, so maybe someone more
enlighted than me could comment on this one and decide if `E_NOTICE` or
 `E_STRICT` is more appropriate.

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

As you can see I changed my opinion as to "abstract". But as to
non-public and static members - you're asking for the engine to simply
ignore modifiers you explicitly give and that make no sense. Programming
languages don't work that way.

-- mp.