BJörn Lindqvist wrote: >On 8/22/07, Gabriel Genellina <[EMAIL PROTECTED]> wrote: > > >>On 22 ago, 10:00, "BJörn Lindqvist" <[EMAIL PROTECTED]> wrote: >> >> >>>As I said, you can accomplish the exact same thing by calling a >>>function from within the function that requires the user to be logged >>>in. >>> >>>def change_pass(): >>> check_user_logged_in() >>> ... more stuff here... >>> >>>is less complex (and therefore preferable) than: >>> >>>@check_user_logged_in >>>def change_pass(): >>> ... more stuff here... >>> >>>An important principle in engineering is that you should always strive >>>to make your design as simple as possible. If you have two equal >>>designs, you should always choose the one that is simpler because >>>simple things are easier to understand than complex things. >>> >>> >>I don't see the complexity in this case - both are a single line of >>code. Any internal complexity is hidden by the language. In fact, I >> >> > >"Hiding" doesn't reduce complexity, quite the opposite. > > > >>consider the decorated function simpler than the other: its body >>represents exactly what the function does, without any distracting >>precondition calls. >> >> > >Think about how the decorator is implemented. It is a high order >function, taking a function and returning a new function. Something >like this: > >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 > >@check_user_logged_in >def change_pass(): > ... more stuff here... > >or: > >def check_user_logged_in(): > return global_state.the_user.is_logged_in > >def change_pass(): > if not check_user_logged_in(): > return show_login_page() > ... more stuff here ... > >or even: > >def change_pass(): > if not global_state.the_user.is_logged_in: > return show_login_page() > ... more stuff here ... > > > >>The decorator has some advantages: can have syntax support on your >>editor, can perform some registering/logging, it's even easier to >>quickly check visually if it's here. >> >> > >The decorator has just as many disadvantages. For example, what if you >want to redirect back to the change_pass page once the user has >pressed the Login button on the login_page? Or if you want to show >different login pages depending on user properties? How much control >flow do you really want to "hide" in your decorator? > > > Thanks Björn. Maybe im blind here in my intent to use decorators somewhere, but even re-checking you samples (pretty much the kind of example i show to my boss), it looks nicer (to me) when using a decorator!! I guess im becoming a `deco junky' :)
Later you expose some interesing points about that login page and redirecting stuff...well, im my case, the login page does depends on user properties, wich (at this point) are stored in a `session data variable' (actually a table row), so the login pages take care about user properties, not the decorator itself, but the other part of the page. I guess decorators has is own public, well, im one of that public. Let my be with my deco-junk alone, you bastard :) Thanks a lot for your opinnions, guys! Gerardo -- http://mail.python.org/mailman/listinfo/python-list
