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.
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.
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".
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.
"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?
As I understand it,
E_STRICTis 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_STRICTis 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 willE_STRICTbe
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.