On Tuesday 23 October 2001 14:11, you wrote: > On Tuesday 23 October 2001 22:43, you wrote: > > While nice in its context, this does not work for many paradigms. For > > (hypothetical) example, I have a class which maintains some state > > information in a database. When an instance is destroyed, I want the > > corresponding state deleted out of the database. But I don't know > > beforehand when an instance is going to be destroyed, because I am one > > programmer on a team of 50 programmers working on this product. It is > > clear that a destructor is the most useful way of handling this > > situation. > > No offence but I think that a good design up front would be the most useful > way of handling this situation. And you work in which mythical shop that does everything "right"? :-) (Just thinking of one project I've worked on... I asked for the MRD so I could do a functional spec, my manager said "I'll get you one but here's what we want", so I prototyped a design, said "Will this work?", "Yes... no, the customer says that's not what he wants..." I repeat request for MRD, manager says "I'll get you one but here's what we want" .... sigh). In the big project that I did in Python, we overlapped design and implementation phases to great extent. The first thing I did was draw the architecture on the whiteboard along with data flows within that architecture, and listed the basic criteria and functionality of the program (the latter was a massive document that I spent a week of meetings and a week of writing to put together). Then we assigned boxes of that architecture to various people, but the innards of chunks were not designed in detail by the project architect and the team leads. Rather, those designs were assigned to the people who "owned" various modules, who were required to document them prior to implementing them (and yes this was enforced :-). People had wide lattitude in how they designed and implemented their particular chunk, as long as they got together with the people at the interfaces to properly document the data being passed and make sure that it met the requirements of all consumers. We managed to write a fairly large-scale enterprise-class program in under six months with a manpower budget that was hilariously undersized for the task we'd been assigned, and I don't know if we could have done it in Ruby. It was doable -- barely -- in Python. I know we couldn't have done it in C++, we'd still be tracking down memory leaks today :-). Point: The "right" way is any way that gets things done in a reasonable way in the least amount of time. Having destructors makes this easier in many cases. A "good design up front" is one of those things that in my opinion is utterly impossible -- designs are created via a process of successive refinement (i.e., top-down), and there's no way up front that you can know everything that's going to be necessary at the very bottom of the design heirarchy. The most you can do is set up a good strong architecture up front where the pieces can be isolated so that each individual piece can be individually designed and etc., because no plan of battle survives contact with the enemy^h^h^h^h^hactual customer. You can request MRD's and spew out functional specs until you're blue in the face and this will still remain true, though of course I do *NOT* recommend going into any project without MRD's and functional specs! (For one thing, when marketing wants "one more feature", it makes it that much easier to tell them "No, we've done everything on our MRD and functional spec, put it on the wish list for version 1.1"). In my opinion, this is why Unix is still with us 30 years later -- its componetized design allowed it to move forward into different market niches as the world changed, even though Unix was never really formally "designed". All projects are organic in the end, and must be designed as such. Requiring high-end consumers to know anything about low-level design of individual modules is hardly something that will enhance future maintainability and added functionality for the program. -- Eric Lee Green GnuPG public key at http://badtux.org/eric/eric.gpg mailto:eric / badtux.org Web: http://www.badtux.org You do not save freedom by destroying freedom