Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » protected interface methods »

protected interface methods

php.internals

(Marcus Börger)

23 years ago
Hello internals, It is of course correct that an interface method cannot be declared private but i think it should be possible to declare it protected. Best regards, Marcus mailto:helly@php.net

Moriyoshi Koizumi

23 years ago
marcus.boerger@t-online.de (Marcus Börger) wrote:
> Hello internals, > > It is of course correct that an interface method cannot be declared private > but i think it should be possible to declare it protected.
I don't see the benefit to allow interfaces to have protected methods as I use abstracts for that purpose. What's your point? Moriyoshi

Jan Schneider

23 years ago
Zitat von Moriyoshi Koizumi <moriyoshi@at.wakwak.com>:
> marcus.boerger@t-online.de (Marcus Börger) wrote: > > > Hello internals, > > > > It is of course correct that an interface method cannot be declared > private > > but i think it should be possible to declare it protected. > > I don't see the benefit to allow interfaces to have protected methods as > I > use abstracts for that purpose. What's your point?
Agreed. As the name implies "interfaces" define interfaces to the outside not to extending classes. Jan.
-- http://www.horde.org - The Horde Project http://www.ammma.de - discover your knowledge http://www.tip4all.de - Deine private Tippgemeinschaft

(Marcus Börger)

23 years ago
Hello Jan, Thursday, July 3, 2003, 6:15:04 PM, you wrote: JS> Zitat von Moriyoshi Koizumi <moriyoshi@at.wakwak.com>:
>> marcus.boerger@t-online.de (Marcus Börger) wrote: >> >> > Hello internals, >> > >> > It is of course correct that an interface method cannot be declared >> private >> > but i think it should be possible to declare it protected. >> >> I don't see the benefit to allow interfaces to have protected methods as >> I >> use abstracts for that purpose. What's your point?
JS> Agreed. As the name implies "interfaces" define interfaces to the outside JS> not to extending classes. Not really. An interface simply describes a protocol subset that must be part of the implementing class's protocol. In that it makes no sense to allow final or private methods in an interface but still a protected member in an interface would describe a subset of a protocol. And hence it would describe a method that must be available with protected or public visibility. Or in other words it would make it possible to hide a method per default from outside. "A derived class must implement it but other classes are not supposed to use it" I came across this when i experimened with __clone.
-- Best regards, Marcus mailto:helly@php.net

Moriyoshi Koizumi

23 years ago
marcus.boerger@t-online.de (Marcus Börger) wrote:
> Not really. An interface simply describes a protocol subset that must be part > of the implementing class's protocol. In that it makes no sense to allow final > or private methods in an interface but still a protected member in an interface > would describe a subset of a protocol. And hence it would describe a method > that must be available with protected or public visibility. Or in other words > it would make it possible to hide a method per default from outside. > > "A derived class must implement it but other classes are not supposed to use > it" > > I came across this when i experimened with __clone.
I don't know what you experienced with __clone exactly, but maybe you wanted the class to allow accesses only from instances that have the same interface as the one being invoked. If so, my suggestion is to let those methods take a parameter that holds a caller instance and filter the accesses to it by the condition applying "instanceof" operator to that instance. p.s. A predefined variable like "$that" which indicates the caller instance would be what you want? Moriyoshi

(Marcus Börger)

23 years ago
Hello Moriyoshi, Thursday, July 3, 2003, 6:50:46 PM, you wrote: MK> marcus.boerger@t-online.de (Marcus Börger) wrote:
>> Not really. An interface simply describes a protocol subset that must be part >> of the implementing class's protocol. In that it makes no sense to allow final >> or private methods in an interface but still a protected member in an interface >> would describe a subset of a protocol. And hence it would describe a method >> that must be available with protected or public visibility. Or in other words >> it would make it possible to hide a method per default from outside. >> >> "A derived class must implement it but other classes are not supposed to use >> it" >> >> I came across this when i experimened with __clone.
MK> I don't know what you experienced with __clone exactly, but maybe you MK> wanted the class to allow accesses only from instances that have the same MK> interface as the one being invoked. If so, my suggestion is to let those MK> methods take a parameter that holds a caller instance and filter the MK> accesses to it by the condition applying "instanceof" operator to that MK> instance. MK> p.s. A predefined variable like "$that" which indicates the caller MK> instance would be what you want? Nice idea, but one thing i wanted is to disable cloning of class objects. The following class makes cloning impossible for all derived classes: class no_clone { final private __clone() {} } but the all classes that should not be cloned must be descendants from that class. So the following interface would disallow cloning by default, although it allows derived classes to reenable cloning: interface no_clone { protected function __clone() } When dealing with classes that handle resources such techniques are very helpful to prevent users from shooting themselves in the knee. Best regards, Marcus mailto:helly@php.net

Moriyoshi Koizumi

23 years ago
marcus.boerger@t-online.de (Marcus Börger) wrote:
> Nice idea, but one thing i wanted is to disable cloning of class objects. > > The following class makes cloning impossible for all derived classes: > class no_clone { > final private __clone() {} > } > > but the all classes that should not be cloned must be descendants from that > class. So the following interface would disallow cloning by default, although > it allows derived classes to reenable cloning: > interface no_clone { > protected function __clone() > } > > When dealing with classes that handle resources such techniques are very > helpful to prevent users from shooting themselves in the knee.
I see. But, is it really a matter of interface? And why don't you declare an alternative duplication method rather than __clone() whose usage is reserved? Moriyoshi

(Marcus Börger)

23 years ago
Hello Moriyoshi, Thursday, July 3, 2003, 7:13:44 PM, you wrote: MK> marcus.boerger@t-online.de (Marcus Börger) wrote:
>> Nice idea, but one thing i wanted is to disable cloning of class objects. >> >> The following class makes cloning impossible for all derived classes: >> class no_clone { >> final private __clone() {} >> } >> >> but the all classes that should not be cloned must be descendants from that >> class. So the following interface would disallow cloning by default, although >> it allows derived classes to reenable cloning: >> interface no_clone { >> protected function __clone() >> } >> >> When dealing with classes that handle resources such techniques are very >> helpful to prevent users from shooting themselves in the knee.
MK> I see. But, is it really a matter of interface? And why don't you declare MK> an alternative duplication method rather than __clone() whose usage is MK> reserved? Clone is always there unless you hide it. And only when it is hidden object cloning is disallowed. So whatever else you declare doesn't hinder __clone from working.
-- Best regards, Marcus mailto:helly@php.net

Andi Gutmans

23 years ago
At 06:03 PM 3/7/2003 +0200, Marcus Börger wrote:
>Hello internals, > >It is of course correct that an interface method cannot be declared private >but i think it should be possible to declare it protected.
Interfaces should not support access modifiers and should by default be public. Andi

Sebastian Bergmann

23 years ago
Andi Gutmans wrote:
> Interfaces should not support access modifiers and should by default be > public.
+1
-- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/

Andi Gutmans

23 years ago
At 01:51 AM 4/7/2003 +0200, Andi Gutmans wrote:
>At 06:03 PM 3/7/2003 +0200, Marcus Börger wrote: >>Hello internals, >> >>It is of course correct that an interface method cannot be declared private >>but i think it should be possible to declare it protected. > >Interfaces should not support access modifiers and should by default be >public.
Just in case I wasn't clear, interfaces *are* meant to be a contract to the outside world and aren't supposed to be used for all sorts of internal hierarchy stuff. If they allow PPP modifiers today then that is a bug IMO. Andi

(Marcus Börger)

23 years ago
Hello Andi, Friday, July 4, 2003, 1:53:48 AM, you wrote: AG> At 01:51 AM 4/7/2003 +0200, Andi Gutmans wrote:
>>At 06:03 PM 3/7/2003 +0200, Marcus Börger wrote: >>>Hello internals, >>> >>>It is of course correct that an interface method cannot be declared private >>>but i think it should be possible to declare it protected. >> >>Interfaces should not support access modifiers and should by default be >>public.
AG> Just in case I wasn't clear, interfaces *are* meant to be a contract to the AG> outside world and aren't supposed to be used for all sorts of internal AG> hierarchy stuff. AG> If they allow PPP modifiers today then that is a bug IMO. Of course they don't! And i should have used other words in my original mail perhaps. Because i only wanted to raise some thoughts about the issue. Allowing protected in interfaces would allow oo tricks that are surely very advanced and very very rare to find if we'd go with them. So i am just threw aside this idea. Best regards, Marcus mailto:helly@php.net

Andi Gutmans

23 years ago
At 01:06 AM 4/7/2003 +0200, Marcus Börger wrote:
>AG> Just in case I wasn't clear, interfaces *are* meant to be a contract >to the >AG> outside world and aren't supposed to be used for all sorts of internal >AG> hierarchy stuff. >AG> If they allow PPP modifiers today then that is a bug IMO. > >Of course they don't! And i should have used other words in my original mail >perhaps. Because i only wanted to raise some thoughts about the issue. >Allowing >protected in interfaces would allow oo tricks that are surely very >advanced and >very very rare to find if we'd go with them. So i am just threw aside this >idea.
OK :) Andi