Re: [boost] Re: in/out parameters, codingstylesandmaintenance

From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2003-05-03 16:37:47

>From: "Justin M. Lewis" <boost_at_[hidden]>

> > > Looking a function signature up becomes a nightmare when there are
> > > potentially 100's of them.  So, that's hardly a realistic solution.
> >
> > I think it is.
>
> If you think it is, then you've never been in the situation where you have
> 1000's of undocumented functions, and you've never had to trace through a
> function where 10's if not 100's of unfamiliar calls are made.  And, if
you
> think it is a realistic solution, then you're really not seeing the
problem
> these classes were meant to address.

Yes, I'm seeing it. It's just that there are alternative solutions to this,
as has been presented.

> Again, old code doesn't need changed, because we all ARE familiar with
> sscanf, but, you wanted examples of people using out or in/out params, and
> there you go, there's an example.  And I said, pretend it's NOT a part of
> the standard C library, pretend it's not a call that everyone is familiar
> with, try to give it a name such that it explains how all of the params
are
> used.  It's my example of why naming convention isn't a reasonable
solution.

And I gave an answer: No naming change is needed in this case, as it's clear
from the type of arguments passed in.

> > In such an environment, your in_out() and out() parameters may be the
> first
> > to go, as people won't bother to use them, and change the signature to
not
> > use them (or provide an implicit conversion to them.
> >
> > Anyway, if you think it's a good idea, why don't you try it out? Letting
> the
> > rubber meet the road may be way more productive, than trying to convince
> > people, without existing practice to refer to.
>
> Of course they'll be used, if they're already a part of the code, people
> aren't going to go strip them out.  Modifying code in a large project is a
> PITA.  Besides, no one is going to go modify code they didn't write just
to
> save them from having to type 5-8 extra bytes.

No?

CVS diff log for in_out.hpp:

Commit message: I'm not going to bother with using in_out()

template<class T>
class in_out
{
+    in_out(T &v) : value(v) {} // So sue me
...

Seriously, though, this was mostly to try to lighten up this thread a
little.

> But, if your argument is
> people are going to go out of their way to destroy clear coding styles,
> then, again, all of the solutions anyone else has proposed are at least as
> likely to be thrown out.

No, people may remove something, if they think they are better off without
it.

> And, again, I HAVE been using these classes.  That's why I brought them
> here.  I had a problem with functions not being clear, I found a solution,
> that's enforceable, in that people using the libraries I write have to
> adhere to it, I know other people like the idea after having discussions
> with them, so I thought I'd see about giving it to boost and having it out
> there where it's easily accessible to a large number of people.

And you have got feedback.

Some of the problem, with this is that readability is very subjective, so
discussions of coding style, what is more readable or understandable
function may be difficult. What some may consider making something more
clear, other may consider it the other way around.

Regards,

Terje