Hi Jason,
Thanks for the info.
I understand how the definition of 'interface' lead logically to
the conclusion that it must be public - I was theorizing a situation where an interface could be used accross a 'classtree'* in a protected manner (which could conceptually be seen as as public interface within the scope of the given 'classtree') - the idea being that only the author of the class has access to interface not the enduser/programmer.
btw: I was not implying anything in PHP should change, merely trying to understand the intended usage (and thanks to some of the comments I have been able to un-crudify my coding practices somewhat).
rgds, Jochem
*by 'classtree' I mean a given class and its descendants
Jason Farrell wrote:
Jochem Maas wrote:
No you will find that definition consistent in any language that uses interfaces, most notably C# and Java. As Wez alluded to, it is a **public** contract by its very definition.Wez Furlong wrote:
An interface is a *public* contract by definition; PPP specifiers just don't make sense there.
out of curiosity:
would that be a definition at the PHP level (i.e. decided by php-devs) or is that definition more widely acknowledged (for want of a better word) (e.g. php-devs used the definition as used in C).
anyway...thanks for knowledge-boost!
Neither does static, since interfaces are instance based.
where as the argument for PPP is wholly understandable, I can't see the logic in saying that interfaces are per-definition instance based. It is the class that implements the interface, but assuming that indeed interface should be instance based then would it not be correct to assume that interface implementation should only be checked if and when a class is initialized (i.e. so a class is used _only_ statically any interfaces it implements should be ignored), as per the following example (which only works if the 'abstract' is uncommented):
<?php
interface Foo { function foofoo(); }
/* abstract */ class Bar implements Foo { public static function barbar() { echo "bar bar black sheep"; } }
Bar::barbar();
?>
I can understand that interfaces more naturally lean towards use with instances rather than static classes - but it seems to me that forcing that is a case of telling users how they must program (I have always had the impression that PHP tried never to force a particular way of doing things) - not that its a big deal, because in the end a non-static method can be called statically if the user/programmer wishes (and then its his problem to make sure the method in question can handle being called that way, i.e. no refs to $this).
Anyway, thanks very much for taking the time to broaden (at least) my knowledge of PHP.
rgds, jochem
--Wez.
On Tue, 12 Oct 2004 09:34:00 +0200, Jochem Maas <[EMAIL PROTECTED]> wrote:
I would be very grateful if you could explain the logic behind not being
able to define public/protected/private/static access modifiers for
interface methods (obviously they are abstract by definition).
AFAICS (not that far I admit!) not being able to define public/protected/private/static for interface methods removes a lot of the power of interfaces (in terms of being able to define specifics)
Cheers, Jason
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
