Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:20083
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 16 Nov 2005 23:54:45 +0100
Message-ID: <00A2E2156BEE8446A81C8881AE117F192C1B40@companyweb>
Thread-Topic: [PHP-DEV] interface method visibility.
Thread-Index: AcXqymuhJMD59G/9Tse88d/Wivph5gAKk5Jg
To: "internals" <internals@lists.php.net>
Subject: AW: [PHP-DEV] interface method visibility.
From: mp@webfactory.de ("Matthias Pigulla")

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=20
> 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 (=3Drandom) behaviour.

> right which meant in one particular case I had to create an=20
> object especially to call the given method, very wasteful,=20
> pointless and the only good reason there seems to be is some=20
> 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=20
> > mark methods as static, so the language could not check if a static=20
> > call is allowed. It simply permitted the call, not setting $this.
>=20
> 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.=20

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)=20
> >>causing a fatal error where before (5.0.2 - 5.0.4) no error=20
> >>what so ever.
> >=20
> > I thought I would never write anything like that - but: What sense=20
> > does "abstract" make in an interface at all?
>=20
> the point is it doesn't hurt _you_ to let _me_ do it. if it=20
> makes sense to me but nobody else thats no reason not to=20
> allow it on grounds of principle when it is clear that it has=20
> 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=20
> > like "var"=20
> > that was ok with PHP4 but is discouraged in PHP5. But you are using=20
> > PHP5 elements in a way that make no sense to the language, so it's=20
> > simply an error.
>=20
> and as I understand it E_STRICT is for pedantic checking -=20
> i.e. check if every t is crossed and every i dotted (so to=20
> speak) nothing perse to do with php4 (or will E_STRICT be=20
> 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=20
> coding in for the past 2 years??? the only thing making it=20
> '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.