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_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?)
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.
