Re: [boost] Re: class proposal

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

    The point all along is that this gives you the ability to enforce
explicitness.  It gives you the ability to enforce a design principle, to a
reasonable degree, even if the caller doesn't know what he's doing, or,
isn't paying attention.  Like I said, it falls under the same principle as
using private data.  If we could trust the users of our classes to NOT break
the rules, there'd be no reason to have an explicit way of enforcing the
design rules.  But, since it's obvious that given the opportunity people
will violate the design rules, and directly access class data, given the
opportunity, and not use the given interface, we all make our data private,
and force people to go through our public interface to modify the state of
our objects.

Well, the same thing goes here.  We have a design principle that people will
violate on the caller side.  People won't comment the code properly, or mark
the function to show that the parameters are changing.  So, here's a way to
force them to.

And, as for making const variables in the function isn't a very effective
way of handling this problem.  I may not want the data to be constant, I may
want to modify it all over the place, I may pass it to all kinds of
functions that take const references, but, that doesn't mean I want it const
throughout my function.  So, the only way to make that method work would be
to do something like:
int x;
const int &x_const = x;

and keep 2 instances of each variable around that DOESN'T change, which
would certainly become a maintenance nightmare.  Since, I think it's
probably the norm that functions NOT modify their parameters.

With the wrapper classes I proposed, you only need to mark the parameters
that DO change, which would be the rare case, rather than the common case,
which is what you propose marking.

----- Original Message -----
From: "Terje Slettebø" <tslettebo_at_[hidden]>
To: "Boost mailing list" <boost_at_[hidden]>
Sent: Thursday, April 24, 2003 12:48 PM
Subject: Re: [boost] Re: class proposal

> >From: "Justin M. Lewis" <boost_at_[hidden]>
>
> > Ugh, that's still missing the point.  Using T& or const T& still
requires
> > chasing down function prototypes when I'm trying to track where a
variable
> > MIGHT be changing.
>
> I addressed that part in what followed: Use of const.
>
> Therefore, I did not miss the point. However, did you get mine? The use of
> const to achieve the same?
>
> > And using meaningful variable names, int may_change,
> > isn't even really feasible, and could be come much more complicated than
> > simply saying
> > func(out(myobj));
>
> The "may_change", etc. was just to illustrate the example code.
>
> > Let's say I have a non-copyable object that is a class member, I'm
> certainly
> > not going to name it m_myobj_may_change, that doesn't make sense
>
> I've never suggested such a thing, either, that had nothing to do with the
> point being made.
>
> > This is like why we have private data in C++, because we KNOW that if we
> > give people the opportunity they wouldn't use the proper methods to get
> and
> > set the internal data, so we don't trust people to properly use our
> classes,
> > we hide the data from them we don't want them to touch.  You're
enforcing
> > your design principle.  The same goes here, you would like for people to
> > make it clear that when they call this function the variable being
passed
> in
> > will be modified
>
> Wait a minute, you have to make sure what goal you have. You said that
using
> T & and const T & only show at the _called_ side, not the caller's side,
if
> a variable may be modified. That's correct. Thus, you need no mechanism in
> the function, itself, to show whether or not the parameters may change, as
> the function signature shows that.
>
> As I first understood your proposal, it was to be able to enforce the same
> constraint on the caller's side: That the caller gets to determine what
may
> or may not be changed. This may be done using const, as shown.
>
> Now, the function author, and the function user, both are able to
determine
> and enforce what may be changed, or not. So what's the problem?
>
> What you're saying is that you'd like the function to enforce that the
> caller specifies, in the calling code, what parameters may be changed, or
> not (according to the function signature). Is this really the function's
> responsibility? To force a certain way of using the function, because they
> _may_ not know what they're doing? It may be hard to break this to them,
but
> if they don't know what they're doing, maybe they shouldn't use C++? :)
>
> The point I was making is that if the function and the calling code is
> written correctly, there's no problem. If someone uses a function, and
calls
> it with a non-const variable, and it takes a non-const reference, then,
> frankly, they get what they ask for.
>
> You make an analogy with classes. Yes, let's do that. If you try to access
a
> class's private member from outside the class (and not being a friend),
you
> get an error. There's no way of changing that, by using in_out(), or
> whatever. Likewise, if you try to call a function taking a non-const
> reference, with a const object, you also get an error. Again, there's no
> special syntax to get around that (short of casting).
>
> > I can't count on them to conform on their own, so I come
> > up with a mechanism that helps enforce it.
>
> Again, this may not be the function's responsibility to enforce. Also,
> people who are familiar with using const for the same purpose, may just
find
> such code harder to read.
>
> > Look at systems programmers,
> > there are instances where bits in registers marked reserved, that were
> > actually still readable and writable, were used to store some extra
data.
> > Now, at least in the processors I've been working on, bits marked
reserved
> > are not writable.  The point here is, given the opportunity people will
> > violate the rules, so the best you can do is make it more difficult to
> > violate the rules.
>
> Yes, but you do that by enforcing the constraints in _your_ functions, not
> the calling code.
>
> > That's really the point of this, it's an enforcable way of explicitly
> > decorating the invocation of functions that change the params passed in.
> > Keep that in mind, decorating the INVOCATION, to prevent me from having
to
> > chase down 100's of function prototypes to see which params are marked
> const
> > and which aren't.
>
> You must of course do what you think is best in this situation. I just
hope
> you got my point that if the calling code uses const, you don't have to
look
> at the function signature, to determine what variables may or may not be
> changed by a function.
>
>
> Regards,
>
> Terje
>
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>