Re: [boost] in/out parameters, codingstylesandmaintenance

From: Joel de Guzman (djowel_at_[hidden])
Date: 2003-05-01 22:54:23

Justin M. Lewis wrote:

> It doesn't need to be used everywhere in every project.  The point
> is, if you're starting something new, and you can be fairly sure that
> it's going to be used for years to come, you can start a project with
> it.  I'm not suggesting that you use it IN the boost libraries even. 
> I just see it as a useful utility for anyone who would like to use it
> to keep their own code clear.

I'll repeat myself: It won't have teeth if it's not enforced. The problem is
that you can't enforce it. You keep on saying that the goal is so that
the coder would be saved "the trouble of having to hunt down all kinds 
of functions to find out if and when you can expect your variables to 
change". If it's not applied globally, then the coder will be as confused
as before. She'll still have to hunt down all function calls to find out if and 
when her variable will be changed or not. The case-by-case nature of
your solution will cause more confusion, AFAICT. When you see:

    foo(a, b, c)

Are you 100% sure, without looking at the docs or the API, that
a, b or c is not modified? The only plausible answer is: that depends,
if foo is retrofitted or not. *** That's the problem ***.  Anything less 
than 100% guarantee is false security.

>> Augustus Saunders wrote:
>> 
>>> Whether or not somebody else actually uses the tool is not exactly
>>> our problem.  We can make sure that Boost libraries themselves use
>>> this idiom anyplace that in/out parameters are called for (aside
>>> from previously mentioned idiomatic usage in some operators) and
>>> guaruntee correct, consistent use.  Conceivably, this idiom could
>>> be useful 
>>> only for our own use, not even as a facitlity that we offer to
>>> library users.  But then again, there seems no reason to withhold it
>>> if we use it internally.  People will benefit to whatever extent
>>> they 
>>> use it, which is fine by me.  My question, then:
>>> 
>>> Is it easy enough?
>> 
>> No. If you force boost writers to retrofit all of their code, that
>> would mean hundreds of thousands, if not, millions of lines of code.
>> I'd 
>> rather spend my time on something more productive.
>> 
>>> Does it work as advertised?
>>> 
>>> Like another poster pointed out, these probably require some actual
>>> usage to answer.
>> 
>> Chicken and egg, AFAICS.
>> 
>>> But I don't think that a lack of global usage
>>> guaruntees hinders the potential usefulness of the idea.
>> 
>> Why? If it's not applied globally, it would be like installing some
> security
>> alarm system only in some places in your house. How useful is that?
>> There would still be uncertainty.
>> 
>> --
>> Joel de Guzman
>> joel at boost-consulting.com
>> http://www.boost-consulting.com
>> http://spirit.sf.net
>> 
>> 
>> _______________________________________________
>> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>> 
> 
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost 

-- 
Joel de Guzman
joel at boost-consulting.com
http://www.boost-consulting.com
http://spirit.sf.net