On 6/1/06, Joost Diepenmaat <joost / zeekat.nl> wrote:
> On Thu, Jun 01, 2006 at 04:29:59AM +0900, Alexandru Popescu wrote:
> > On 5/31/06, Joost Diepenmaat <joost / zeekat.nl> wrote:
> > >On Thu, Jun 01, 2006 at 03:57:08AM +0900, Alexandru Popescu wrote:
> > >> At least in Java these modifiers are quite usefull: a protected method
> > >> is one that offers extensibility/polymorphic behavior for hierarchies,
> > >> without exposing it as public API. So the behavior may vary according
> > >> to the implementation, and the exposed API/public methods are a
> > >> completely different thing.
> > >
> > >That's only true if you also find some way to stop the "public" from
> > >inheriting from your base classes too, and I cann't think of any language
> > >that allows you to do that.
> > >
> > >Protected methods *are* part of the public API anyway - might as
> > >well admit it and make them public and put a big disclaimer in the
> > >docs.
> > >
> > >Joost.
> > >
> >
> > Not sure I am getting your argument. For inheritance this is the exact
> > needed behavior. Any external object will still be not able to call
> > these methods. So they are providing a way to customize your internal
> > implementation when working with hierarchies, but not offer it as an
> > API method.
>
> My argument was that you then have to disallow people from implementing
> their own classes based on your classes, because if they do, they still
> can call the protected methods you just worked so hard to "protect".
>

But I haven't worked on protecting them against overridding, but
against direct calls. Big difference.

> My main point though, is that if you think you need protected methods you
> should think really hard about wether other classes might find those
> methods useful too (i.e. just make them public instead).
>

This is a matter of the API designer skills. However making everything
public, for the sake that somebody may find one of the methods usefull
is imo worse than having to evolve your initial API.

> I've ran into too many problems with libraries where you just can't call
> very handy methods because the designer decided you shouldn't and then it
> takes hours to work around that. My gut feeling is that protected methods
> are usually either badly designed, or made so the designer can feel good
> about not binding the API to the implementation. If your implementation is
> so bad you don't want _other_ people relying on it, but _you_ still need
> access to it to make your code work, you're doing something wrong.
>

It's sad to hear this, but unfortunately I would say that it was your
bad luck to work with bad designed APIs. Agreed, some projects get it
right from the 1st version, other are learning how to do it.

./alex
--
.w( the_mindstorm )p.

PS: probably we just have to agree to disagree :-). For me protected
is usefull and has been. Bad APIs is another topic and in some of the
companies I have worked for there were specific people for designing
the APIs for the frameworks used by hundred of other developers (I was
one of them :-) and frankly speaking, so far,  I haven't had such a
bad feedback as you describe).

> I'm open to the idea that protected methods can be useful, it's just that
> I don't like most uses of them that I've seen.
>
> I feel the same about "friend" functions & classes in C++ (harcore
> performance reasons only, I'd say)
>
> YMMV,
>
> Joost.
>
>
>