Express What, not How.

Darius ddarius at hotpop.com
Wed Oct 15 17:01:45 EDT 2003


Raffael Cavallaro <raffaelcavallaro at junk.mail.me.not.mac.com> wrote in message news:<raffaelcavallaro-30C16C.09424315102003 at netnews.attbi.com>...

> I thought it was obvious that I was not advocating eliminating anonymous 
> functions entirely, since I said they should be used inside named 
> function bodes.
>
> To be completely clear, I'm advocating only using anonymous functions 
> when two conditions are met:
> 
> 1. When the functionality provided is _unique_. If that which the 
> anonymous function is performing is also done elsewhere, especially if 
> it is done in several different places throughout the code, then that 
> anonymous function should be recast as a descriptively named function or 
> macro.
> 
> 2. If it is necessary to show, at that _particular_ source location, 
> _how_ a piece of functionality is provided. If the reader doesn't need 
> to know _how_ things are implemented in that _particular_ source 
> location, we should use a descriptively named function or macro instead.

The reason people are attacking your posts is because the above has
NOTHING to do with anonymous functions.  This advice should be
followed independent of anonymous functions.

1. When the functionality provided is _unique_. If that which the 
code is performing is also done elsewhere, especially if 
it is done in several different places throughout the code, then that 
code should be recast as a descriptively named function or 
macro.

2. If it is necessary to show, at that _particular_ source location, 
_how_ a piece of functionality is provided. If the reader doesn't need
to know _how_ things are implemented in that _particular_ source 
location, we should use a descriptively named function or macro
instead.

Further in response to 2, limiting the use of anonymous functions to
only named functions that are showing how things are implemented
doesn't limit them at all!    You are virtually always in a named
function and you are always showing how to implement something. 2 is a
null statement.  Nevertheless, what (I presume) you were intending
(something along the lines of 'create and use abstraction barriers'
again has nothing to do with anonymous functions or at least no
special attachment to them.

Finally, all this advice (generalized to include all code) is a)
obvious to anyone who has been programming for more than half a day,
and b) quite standard software engineering advice.  The reason why
your position is being extended beyond your intent is simply because
people presumed from your statements of the obvious and focus on
anonymous functions that you were attempting to state something other
than the obvious.  To end this post, I feel I should bring special
attention to the fact that people over 1.98 meters should be wary of
dangerous things.




More information about the Python-list mailing list