Mark Ramm wrote:
> I agree with that on some basic level, but I also think it's
> important to differentiate @validate from @expose.
Okay, I sort of agree, and sort of disagree with you here...
> @validate is designed to change the method signature, whereas
> @expose should not.
This should read "@validate *was* designed to change the method
signature", but that doesn't mean that it *has* to be done this way.
Personally, I find decorators that change the method signature to
be a little bit difficult to understand, and if its hard for me to
understand, then its probably going to be really hard for beginners
to understand.
I believe that we can get all the functionality that we need in
@validate, without having to do crazy things, or create nutty stack
traces.
> @validate is a reasonable candidate for somebody to switch out
> with a new implementation, and @expose is not.
I agree with you here, but there are two ways we could do this that
are far less insane than creating a "wrapping" decorator:
1. Allow our @validate decorator to take in callables to perform
generic validation, and error handling code that someone
defines on their own. This way, people can do whatever they
like.
2. If someone wants to replace the implementation of @validate,
then they should create their own decorator, not monkeypatch
TurboGears to use their implementation.
So, I don't see this as a good argument, personally.
> I'm not so worried about @validate as I was about expose,
> the decorator version of @validate wouldn't require extra
> work to maintaint the method signature, and would have a very
> well-understood scope. I haven't done it, but I think the "actual
> wrapper" version of validate wouldn't be much more code, or much
> more difficult to read.
It'll still mangle stack traces, though, which is a big deal to
me. Also, decorators that perform real "wrapping" instantly become
significantly more complex, as they have to make sure to "migrate"
all of the function attributes from the old function to the newly
wrapped function.
> Alberto particularly wanted to be able to supply his own validate
> in ToscaWidgets, and if there's signficant benifit in letting
> people tweek validate, it makes sense to decouple it from the
> controller so that people could much more reasonably do that.
I can certainly understand that, but again, I think we can
accomplish this without having to sacrifice the elegance of the
current solution, or making the decorator more complex than it needs
to be. I'd rather see us design @validate to be extensible by
passing in callables.
Just my two cents...
--
Jonathan LaCour
http://cleverdevil.org
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears Trunk" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk?hl=en
-~----------~----~----~----~------~----~------~--~---
