Hmm, did I missread you or did you get me wrong? Anyway, private will not allow anyone to inherit and extend, it will allow someone to reimplement. Ie, if you have
class Foo { private void a(); }
class Bar { inherit Foo; void a(); }
then Foo.a is not visible from Bar at all. Only Bar.a is accessible.
/ Marcus Agehall (nu med semester)
Previous text:
2004-07-23 07:37: Subject: Re: Access control
Marcus Agehall (nu med semester) @ Pike (-) developers forum wrote:
Come to think of it, private might be right anyway. Of course one may subclass and override, but that is only because the private methods and classes does not exists (well, they aren't visible anyway) in the subclass. If the intention is to create a class that should only be accessible from your code and never used by subclasses, I would go for private.
Yes, private doesn't sound so bad. What I want is to prevent other code outside of the module to instantiate new objects from the class, but of course, it won't hurt if another module is able to extend the class by inheriting it, and then do what ever it's up to do. It's to different use cases, whereas the first would prohibit a "end user" from abusing the class (should only get already created objects to work with, not create his own ones) and the second is for a class to be able to extend the functionality and present a new object for the end user to use.
It's all a matter of defining and make the design apparent how to (and not to) use the module. It'll be put on modules.gotpike.org as soon as I have it working with monger, so feel free to have a look and come back with feedback :o)
Anyway, the modifiers in pike are somewhat confusing if you try to apply knowledge from some other language to them...
Indeed, I use to have the documentation for access control open to have a quick glance when I get confused.
Thanks, Andreas
/ Brevbäraren
pike-devel@lists.lysator.liu.se