Re: Re: Interfaces and Access Levels

Jason Barnett wrote:

Gerard Samuel wrote:

I would like bar::do_something_internal() to have an access level of *private* But this would fail, as the interface can only have *public* methods. Is there a way to get bar::do_something_internal() to be private? Or am I SOL, and it has be public? Thanks interface foo {

    function do_something_internal();

} class bar implements foo { private function do_something_internal() {

       // I would like this to be private

} }

Interfaces, at least as far as PHP is concerned, is kind of like the "minimum standard" for an API. An interface is a contract with the outside world only... no promises on how the work gets done be it one big function or several internal functions to help it. I simply don't understand why you want to require a class to have a method that will never be accessed outside of the class. Perhaps using abstract classes / protected methods will work for your purpose? http://php.net/manual/en/language.oop5.abstract.php

The reasons can be many. In my particular case, the method I would like to be "private" is a *helper* method that constructs a database select LIMIT. It only makes sense within the class, not outside the class, thus Im making it private. Since each database driver is going to have this method, I would like it to be part of the interface API. The problem with using an abstract class, is that its a class. Each driver (as Im constructing them), must implement an interface, and extend common code. I.E. class foo extends common implements bar { function do_something() { } } This would not be possible with an abstract class. It would be nice if interfaces access levels work the opposite of abstract access levels. When extending an abstract class, the *extender* must use the same level or *weaker* visiblity. For interfaces, the *implementer* can use the same level or *stonger* visibility. If that were possible, the contract is maintained, while making it possible, to apply *stronger* visibility in the implemented classes. That is just an idea of mine. Thanks for listening... [After thought] I was proof reading my reply, and the thought occured to me, that I can have the so called common code be an abstract class, that contains the neccessary methods for the *contract*. Well that thought, just blew away my reply ;)