Date: 2001-10-31 14:12:40
--- In boost_at_y..., "Kevin S. Van Horn" <kevin.vanhorn_at_n...> wrote:
> On Tue, 30 Oct 2001 williamkempf_at_h... wrote:
> > --- In boost_at_y..., "Kevin S. Van Horn" <kevin.vanhorn_at_n...> wrote:
> > > I'm going to go out on a limb here and say that I am
> > > of the opinion that non-static member functions are usually a
bad idea, as
> > > they produce brittle designs and expose implementation
> > OO experts will strongly disagree about all of this.
> Of course, the priests of any religion will disagree when you
> orthodoxy. Not that I'm against OO in general. It's just that I
think a lot
> of OO advocates go overboard and think that their particular notion
of OO is
> the one and only true path to programming perfection.
That really doesn't apply here, however. You're simply arguing for a
different religion (generic coding).
> [I discussed Three possibilities: (1) public member function; (2)
> function; (3) non-member, non-friend function. I stated that I
> when possible, and lean toward (2) over (1). The reason is to
> to the internals of a class to only those functions really needing
There's a reason to prefer (3) in a general sense. I forget the OO
principles name, but in essence the public interface should
be "minimal but complete". This principle can be taken too far,
(2) on the other hand should never be prefered. Friend functions are
fragile and can open the code up to abuse. They also clearly
illustrate that the above principle wasn't adhered to. This is
precisely the problem I have with the desire of those following
the "generic" religion to make all functions free functions.
> > In general I'd agree. However, the problem with this reasoning
> > becomes appearant when the internals change making the non-member
> > function implementation overly innefficient in comparison to an
> > equivalent member function.
> That's when you go from (3) to (2). Member functions have no
> advantage whatsoever over friend functions.
> [I discussed the problem with (1): Once a member function, always a
> function, even if in a later implementation the function doesn't
> to the class internals.]
This argument is, again, very weak IMHO. I see nothing wrong with
the function remaining a member function, and no compelling argument
has ever been given as to why you should find this to be bad.
> > I've already shown that this argument is weak. We can trivially
> > change (actually, just extend) the syntax to allow for
> > (x) [instead of x.some_operation()].
> You miss the point entirely.
No, I really didn't.
> Sure, you can always define a non-member
> function that is just syntactic sugar on top of the member
> you can't do is prevent people from using the *public* member
> a function is declared as a member function, there's nothing you
can do to
> stop library users from writing x.some_operation() instead of
> some_operation(x), and hence you cannot later make some_operation()
> non-member without breaking existing client code.
1) Why should you prevent them from writing x.some_operation()?
2) some_operation() already *IS* a non-member (as well as a member)
so this is a non-issue.
The arguments here are purely about syntax. In general I believe
most folks are going to prefer the x.some_operation() syntax as this
is the syntax used by (nearly?) all OO languages. The only
compelling argument for the some_operation(x) syntax is for use in
generic algorithms, but if both forms of the syntax are provided this
becomes a non-argument. Sorry, you've not provided ANY compelling
arguments for changing the "normal" syntax here.
> > > The problem would be resolved, of course, if it were not for the
> > > syntactic flaw that C++ inherited from Simula of using the
> > > object.function() syntax [...]
> > Simula is hardly the only OO language that uses this syntax.
> It was the first.
> > You can argue that maybe the syntax isn't optimal, but it is the
way it is
> > and it's what OO designers expect. So the argument is pointless.
> No, it's not pointless, as there will be new languages defined in
> and it would be well if the designers of those languages would
> these issues instead of thoughtlessly repeating a mistake that is
It's not a mistake, however. The only existing language for which
any argument can be made for this syntax being a mistake is C++.
It's unique in this regard because it has both generics and free
standing functions. Eiffel, for instance, has generics but no free
standing functions so the syntax x.some_operation() (not quite the
syntax used by Eiffel, but lets not get bogged down here) is fully
well thought out.
As for C++ itself, I still see no compelling reason. None. A simple
wrapper will adapt the member function approach for generic
algorithms which expect the free function approach.
> > Templates and generic programming have lead to some slightly
> > different views on design, but unless a concept is specifically
> > to be used by generic algorithms (range may be such a concept)
> I think you have this all wrong. You have to assume from the
> anything might be a candidate for generalization, if not now then
> future, and therefore one should avoid unnecessary semantic and
> diversity. For example, if C++ had insisted on using different
> operators for float addition, integer addition, and double
> numeric algorithms would be substantially harder to write and
> (I will admit that there are strong arguments for syntactically
> integer divide and floating-point divide, as there are important,
> semantic differences between the two.) My biggest beef against
Java is the
> great semantic and syntactic gulf between primitive data types and
> user-defined types. This nonuniformity torpedoes any possibility
> generic programming in Java, even if templates were added to the
> makes even limited generic programming very awkward and difficult.
The language syntax was designed before generics existed. For this
reason it has a heavy bias towards the x.some_operation() syntax.
Generic algorithms have a choice for supporting either syntax, and
often it will be appropriate for them to use the x.some_operation()
syntax. When an algorithm does use the some_operation(x) syntax I
can trivially provide an adapter. So I find it to simply be wrong to
program the interface assuming a generic usage. It makes the design
more fragile while not giving me anything I can't get with the more
traditional design. So, again, I've yet to see a compelling argument
> > then I still feel strongly that it's wrong to not use standard OO
> > C++,
> That sounds a little dogmatic to me. I believe as strongly as
anyone in the
> importance of encapsulation and abstraction; I just don't have the
> believer's unquestioning faith that current OO prescriptions are
> the best way of achieving those goals. Allow me to point out that
> field of generic programming -- and much of the current vitality of
> arose because Stepanov, Musser, and others weren't willing to stick
> "standard OO designs" in the quest for generality and code reuse.
Yes and no. Notice that the containers have always been designed
with traditional OO principles (i.e. member functions instead of
friends). Adapters of sorts (the iterators) were used to bridge from
the OO paradigm to the generic algorithm paradigm. I believe that
this was the appropriate design choice, and is consistent with what
I've been saying here all along. C++ is unique among languages in
that it allows us to program to multiple paradigms (OO, procedural,
generic, interface, etc.). You have to carefully evaluate which
paradigm is appropriate for a given task and write code that bridges
between the various other options. This means that I find it flatly
wrong to avoid member functions simply because there might, maybe,
someday, be a generic algorithm which is going to use a free standing
> > I've yet to see an argument for the "free function" design
> > that's convincing.
> I've yet to see any argument that the syntactic distinction between
> nonmember functions serves any useful purpose.
That's a different argument, and simply doesn't apply since C++ does
distinguish between the syntaxes. Trying to work around this through
kludges (making functions friend instead of member) simply isn't
appropriate. Don't argue for the syntax, because we can't change
that, but argue for the design.
> As argued above, we should
> strive for syntactic and syntactic uniformity as the norm,
departing from it
> only with good reason and to the extent necessary. The difference
> "free function" (using friends) and member function design is purely
No, it's not purely syntactic. Differences:
1) Friends are fragile and are open to abuse.
2) Free functions pollute the namespace.
3) Free functions don't clearly indicate the coupling to the object.
Since they simply do not buy you anything I can not agree with a
desire to use friend functions instead of members.
> From a standpoint of conceptual economy, support for generic
> programming, and flexibility to grant or deny access to the innards
> class, I prefer the uniform syntax.
If it were purely syntax you'd have more of an argument, but it's
not. In any event, I prefer the x.some_procedure() syntax any way,
so I'd argue that if you want uniformity we should make everything
follow this syntax ;). (This is said only half facetiously to
illustrate the religous bias being shown.)
> > > [Proposal to avoid the need to declare private member functions
> > > public header files.]
> > [...] employ the PIMPL idiom.
> That works sometimes, but what if you want a lightweight class and
> to be doing dynamic memory allocation all the time?
There are often ways to achieve this. Granted, not always, but then
I often question the desire to hide things to this extent any way.
> > However, private functions don't truly
> > expose implementation details, at least not to the extent that
> > matters.
> I'm more concerned with unnecessarily large header files and having
> recompile all source files that use a class just because I
> class implementation code to factor out some common functionality.
Header decoupling. I wish there was a universal solution to this in
C++, but I don't know of any. The "friend" approach isn't going to
save you here. The only approach that will is the PIMPL idiom, but
as you pointed out this is often a rather runtime-expensive solution.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk