$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: Noel Yap (Noel.Yap_at_[hidden])
Date: 2003-05-04 18:12:20
"Justin M. Lewis" wrote:
> That's not rigorous review, when you obviously KNOW the point, then ignore
> it to nitpick the example, which was used only to show the basic use, not
> give a real world example. You know I could come through, and make the
> example more complex, and give my classes more members, and make my
> functions do more so that their existence would be justified. You know in
> the case of the non-copyable object that cases exist where you have a
> non-copyable object that you pass around and modify.
No, we don't know that; we haven't seen any code that can't be
rewritten.
> Basically, you don't like the idea, that's fine. You wouldn't use it
> yourself, that's fine. But, nitpicking the examples is hardly constructive.
> Attack the idea, that's really the point of all of this. You can say you
> see no use for it. When I was doing COM I didn't either. It wasn't until I
> was dealing with very large projects with legacy code that had been around
> for years that I got frustrated with this problem.
I can't speak for the others. I don't like the idea because there are
other, IMHO, better ways to program that make clear the intent of a
function.
You seem to be insisting that none of the proposed solutions are
possible in your situation, but you haven't shown a situation where it's
not possible. Your replies aren't too helpful either without any code
to justify them.
> Basically your argument is, you've never experienced the problem, so it must
> not exist. I can tell you first hand, the problem does exist, and there are
> people who have to deal with it on a daily basis. This is my solution to
> the problem, if there's a better solution, I'm open to hearing about it.
Again, I can't speak for the others. My argument is that I've seen the
problem and it's a sign of poor coding and design -- a band-aid isn't
going to help a hemorrhage.
> I have appreciated Noel's comments very much in that aspect, and the others,
> who have suggested alternatives. But, so far, the alternatives, I think,
> fall short of the intent of my proposal.
Thanks for the appreciation :-) I can't understand the arguments
against the proposed solutions (other than some may use non-existent
classes) without seeing code demonstrating they're infeasibility. Can
you post some, please?
Thanks,
Noel