Re: Re: Interfaces and Access Levels

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 ;)

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux