Re: [boost] [Boost.Breakable] Any interest in a Boost Breakable library?

Subject: Re: [boost] [Boost.Breakable] Any interest in a Boost Breakable library?
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2009-09-09 10:37:26

Pierre Morcello wrote:
>
> 0/ just a side note.
[snip]
> So the name of the function, must be chosen
> carefully to suppress any doubt from the reader.

Of course.

> 1/
> One side effect in your approach is that it forces the user
> to declare the function in the .h. If there is no use to
> reuse the code (because it is extremely specific to the
> function), then you are polluting the .h with things that are
> not information specific to the class, but only to one function.

Not true.  Even if the original code in question is in a member function, the other functions need not be so.

> 2/
> If I have to declare the function in the .h, I may end
> writing : "void _myfuntion_findLoadedMeshes()" in private,
> with a doxygen description on top of it. Why such a
> description if the code is 'self explanatory'? The reason is
> : each of my function got a set of preconditions to tests,
> sometimes post conditions, and I would not ask someone to
> maintain a system without these informations. Without these
> comments, I suppose I will also end asserting everything in
> the code I already already tested back in the 'parent'
> function. As a matter of fact I have already seen guys who
> were testing a boolean member as a precondition to see if the
> function was called just after the 'supposed previous call'.
> So there is a need to restrain the use of the 'sub-function'
> to the 'parent function' only.

If the subfunction must be a member, then it must be declared in the class definition.  I don't begin to understand why it must be documented for Doxygen.  Implementation details should not be documented for users.

For preconditions and postconditions of implementation detail functions, I rely on assertions.  Documentation can easily become dated and the maintainers can easily follow the assertion logic.

> My conclusion on this 'keep the h clean' part is : if the
> 'sub-part' is big or to be reused, 'function split' (as you
> proposed) or even aggregation is the way to go. If the
> sub-part is very specific and 'middle-big', a local struct
> with methods is much nicer. In the last case, if the
> 'sub-part' is little and very specific, you will appreciate
> the 'Breakable' idiom.

I haven't argued that your "Breakable" idiom is a bad idea for all cases, but I did address the specific example you cited and showed a very readable alternative that avoided the "Breakable" approach.

> 3/ possible errors creation during subfunction writing.
> When you write the 'Breakable', you are only writing 1 line.
> It is very hard to write something wrong at that level.
> When you declare the subfunctions, you have to declare the
> parameters, also gives them meaningfull names. Most of the
> time, let say I have between 2 or 3 parameters to give to the
> subfunction. 1 time out of 3 I have a std container to
> transmit. Someone with less experience than me (or myself
> when I am tired) could write "bool
> find_loaded_meshes(std::set<Mesh*>  _meshes)" and forgetting
> the & in the definition. Then copy/pasting the result to
> write quickier its declaration, it stays the same. Then, if
> the function is just checking things inside the container,
> you got a real performance hit for free. Otherwise you will
> find this error soon when it bugs.
> So conclusion on that point is : this will take you more time
> and length to code, and is more prone to some errors (even if
> they are rare / not tragic).

I've never found such problems to be common among my peers or in my own code.  If your cadre is prone to such things, then it is a real concern.  However, your approach increases coupling and decreases cohesion.  There are always tradeoffs and one must balance the forces as appropriate to a given context.

> 4/ People write a function when they need one, not in order
> to manage a syntax problem. You supposed I don't know when I
> should write a function. Well, as a matter of fact, the
> problem is the other way round : I am studying the case when
> the user knows he does not need any function at that point,
> and he only needs syntactic sugar.

I write a function whenever it makes my code clearer, reduces coupling, increases cohesion, increases reuse, etc.  Syntactic sugar is a nice thing to have when it doesn't cause cavities.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.