Re: [boost] in/out parameters, coding styles and maintenance[was:class proposal]

From: Justin M. Lewis (boost_at_[hidden])
Date: 2003-04-26 18:14:24

I don't think it's reasonable to compare how things are done in the standard
library to how things are done in actual code.  The standard library is
STANDARD, we all KNOW what it does, and how it behaves, and it's documented
all over the place.

My code on the other hand, it's not standard, you have no way of knowing how
anything I wrote works, without learning the entire source.  And, when we're
talking about projects that are potentially millions of lines of code,
that's not governed by any standard, the problem of figuring out what's
going on becomes a real issue.  So, I'm not advocating, or even suggesting,
that the these classes be applied to things like the standard library.  I
think they would be a useful tool for any large project that will be
maintained for years on end.

Again, try to imagine the situation where you're browsing through source
files that are 10's of thousands of lines long EACH, looking at 100's of
unfamiliar function calls, trying to trace how some particular module works.
You have the option of looking up every function that's called, then every
function every one of those functions call to see what is ultimately
happening to the parameters, or, in an environment like I'm suggesting, it
would be obvious at the invocation point what is happening to the
parameters.

> I prefer some degree of abstraction and information hiding.
Could you explain that to me.  Information hiding?  I'm not terribly fond of
functions that attempt to hide their purpose from me, that doesn't even make
sense.  And, some degree of abstraction?  What is it you want to abstract?

> 1. I think liberal use of out parameters is bad practice, and I have
>    no interest in a library which makes bad practice more palatable.
>    But if you're bound and determined to do it, by all means clarify
>    by whatever means neccessary.
I don't think I've ever suggested that out parameters should be the NORM.
I've said that they are practical at some points.  And, I still can't see
how making it explicit is a bad thing.  I can't even see how out parameters
are bad practice, that seems like a bit of an over generalization.  In some
of the simple examples I give here they'd be bad practice, but, in real
code, there are places it makes sense to use out params.  out and in_out
params are used all over the standard libraries.  They're used all over the
Windows API.  And they're obviously used in things like COM and CORBA.  And,
in other projects I've worked on, they're not the norm, but they're not that
uncommon.  Jumping through hoops, and taking potentially large performance
hits to avoid their use seems ridiculous to me.

And, again, while you personally may not like their use, they ARE used.  And
the whole point of this is to make their use explicit and clear, so when
someone like you comes along the outcome of the function is clear to YOU,
the person coming in to maintain the code.  Not to ME the person writing the
code.

Justin

----- Original Message -----
From: "David Abrahams" <dave_at_[hidden]>
To: "Boost mailing list" <boost_at_[hidden]>
Sent: Saturday, April 26, 2003 9:50 AM
Subject: Re: [boost] in/out parameters, coding styles and
maintenance[was:class proposal]

> "Justin M. Lewis" <boost_at_[hidden]> writes:
>
> > You're missing the point.  Personally I see the need for out and
> > in/out params.  While some of you may not like them, I use them, as
> > do others.  The question then becomes, when reading my code, would
> > you rather see
> >
> > f(x,y,z);
> > or
> > f(out(x), in_out(y), z);
> >
> > Would you rather the outcome be obviously clear?  Or would you
> > rather have to track down the source?  The same thing goes for if
> > you were reading code that someone else wrote who used my library,
> > which way would you prefer it?  Would you prefer to have to have a
> > complet understanding of every single function call made in a
> > program or would you prefer that as much information as possible is
> > given at the point of invocation?
>
> I prefer some degree of abstraction and information hiding.
>
> > You're welcome to go out of your way to write your code to never use
> > out or in/out params, although I think that's impractical in a lot
> > of cases, that doesn't mean that everyone else is going to do the
> > same.
>
> I didn't say "never", I do it only when it's idiomatic and hard to
> misunderstand.
>
> I'm reluctant to accept your idea for two reasons:
>
> 1. I think liberal use of out parameters is bad practice, and I have
>    no interest in a library which makes bad practice more palatable.
>    But if you're bound and determined to do it, by all means clarify
>    by whatever means neccessary.
>
> 2. I'd hate to see a facility like that applied where mutable
>    references are already idiomatic, e.g:
>
>        out(cout) << 3;
>        out(x) += 2;
>        std::swap(in_out(x), in_out(y));
>
>    Techniques designed to increase safety and clarity should usually
>    come with simple and uniform rules for when they are applied.
>
> -Dave
>
> --
> Dave Abrahams
> Boost Consulting
> www.boost-consulting.com
>
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>