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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
