On 8/24/07, Gabriel Genellina <[EMAIL PROTECTED]> wrote: > En Thu, 23 Aug 2007 09:20:21 -0300, BJörn Lindqvist <[EMAIL PROTECTED]> > 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 -- http://mail.python.org/mailman/listinfo/python-list
