Re: [lmi] Naming certain overloaded functions

[Greg Chicares]

On 2006-10-26 15:52 UTC, Vadim Zeitlin wrote:

[snip discussion of 'bool' here:
    void do_write(xml_lmi::Element&, bool light_version) const;
which we all agree on changing]

>  Then the only question is: should we change this right now or wait for
> after the merge? I'd prefer to fix it a.s.a.p. while this discussion is
> still fresh in our minds if possible.

I have no objection to changing that now.

As for merging, let's coordinate our strategy. Do you or Evgeniy
plan to make other changes on this branch--and if so, can you
describe them? I'd guess you're finished except for

 - speeding up the calculation summary
 - any issues we might raise in testing (which begins soon)

Knowing that, I can begin merging in earnest. Once the branch is
stable as far as you're concerned, perhaps modulo the list items
above, then maybe we should either tag it, or possibly even create
a new branch off the existing branch. In your experience, what
would seem best?

That aside, I'll probably proceed by making a large number of small
changes. That's the way I normally develop anyway, because I fear
the Big-Bang Integration antipattern. Probably I'll make most such
changes in HEAD, but I might make some in the branch, too (like the
'(*this)[]' thing we discussed earlier today). And there's some more
xmlwrapp --> libxml++ refactoring I'd like to do on the branch first
anyway. Maybe this shouldn't matter to you at all, but I thought it
would be better to mention it.

Of course, others here will test the branch, before any merge. It is
conservative to: test branch and head; then merge in cautious little
steps, testing along the way; then test the merged final HEAD. If I
knew a more conservative way, I'd probably choose it.

I've seen projects "managed" by handing down a ukase like "no change
will be accepted after 200X-YY-ZZ." That's faux conservatism, serves
only to assign blame, and always gets violated anyway. If we find a
few things that we want to improve, then we improve them. But let us
strive to identify them sooner rather than later.