Hi > Possibly - depends on the situation. Here's a possible alternative to > think > about: if you describe the return from F1 independently, and then you > change > F2, you have to update the comment on F1 - a maintenance overhead. But if > F1 > always says "Returns the result of calling F2()", then it never needs > updating (unless the method F1 itself changes, in which case you'd > obviously > have to update the comment anyway, as with any other function).
No. I think you're proving my point father. :-) F1() should always do what it's name suggests (although of course F1 doesn't suggest anything in this particular case). If you change F2() to the point where it effects F1() and F1() no longer does what its name suggests then you have broken F1() and your interface. > If F1 is designed to be a wrapper function only (e.g., the myriad of MFC > classes that more or less simply wrap GDI components), then I would > suggest > that what I offered is the more sensible approach; but if it is more than > a > simple wrapper, then I totally agree with your encapsulation comment. Yes, but even simple wrappers abstract and encapsulate. It's a key concept in C++ that you don't care what goes on behind your interface as long as the functions or member functions do what their names suggest in the context. Regards Paul Paul Grenyer email: [EMAIL PROTECTED] web: http://www.paulgrenyer.co.uk Aeryn: http://www.aeryn.co.uk Metal. Is there anything else? _______________________________________________ msvc mailing list [email protected] See http://beginthread.com/mailman/listinfo/msvc_beginthread.com for subscription changes, and list archive.
