advice about `correct' use of decorator

[BJörn Lindqvist]

On 8/24/07, Gabriel Genellina <gagsl-py2 at yahoo.com.ar> wrote:
> En Thu, 23 Aug 2007 09:20:21 -0300, BJörn Lindqvist <bjourne at gmail.com>
> escribi�:
>
> > def check_user_logged_in(func):
> >     def f(*args, **kwargs):
> >         if global_state.the_user.is_logged_in:
> >             return func(*args, **kwargs)
> >         return show_login_page()
> >     return f
>
> I think there is a semantic problem, perhaps we are not talking
> about the same thing. I'm considering the software complexity AS
> PERCEIVED BY THE PROGRAMMER, looking at the interactions between a
> program and a programmer who is working on some task; some people
> would say "cognitive complexity" to make it clear.

There is no semantic problem. You are just mistaken in your belief
that the complexity that the user of the decorator has to deal with is
different from the complexity in implementing the decorator.

> Which API is more complex: one in which you can play a movie with
> just a single call like PlayMovie(Title), or one on which you must
> call a zillion functions to firtly initialize the stream format,
> configure the display, disable undesired user interfase elements,
> locate the movie file, load it in chunks, etc.? The first one is
> certainly much simpler to use (simpler = less complex), and maybe
> internally it calls the same functions as the second one, but nobody
> cares.

"nobody cares" is your guess. I'd bet that the caller of the PlayMovie
function cares a lot: Is the movie played full screened? Which
encodings are supported? Can you set the title of the movie window? Is
streaming supported? Does it even work on windows? Which URI schemes
does it support?  And so on and so on.

That is why no video decoding API:s have a PlayMovie(Title) function
and why I haven't seen a single 3d engine with a
MakeReallyCoolDoomCloneFPSGame() function.

"hiding details" only works if the client programmer really doesn't
care about the details.

> Back to your example, the fact that a decorator builds a higher order
> function, does NOT make it more complex - because the programmer does not
> see that. In fact, hiding the details makes it simpler.

Yes, the programmer does see that. The example decorator I posted
requires about a zillion preconditions to work correctly and will fail
in weird ways when those preconditions are not satisfied. The
programmer is interested in the crazy failures he or she will
experience. I dare you to try and implementing the code both as a
decorator and as a function, then write the unit tests and
documentation. The complexity of those three items together
(implementation + tests + documentation) will be much higher for the
decorator choice because the complexity of the decorator
implementation is a bit higher than using a plain old function.

Note also that it is extremely rare to see well-documented or
well-tested code, which means that the programmer WILL have to analyze
the implementation which means that implementation complexity matters
a lot.


-- 
mvh Björn