> Non-generic function approach:
>
> def do_something(obj):
> if instance(obj, basestring):
> do_something_with_string(obj)
> if instance(obj, int):
> do_something_with_int(obj)
> else:
> do_something_default(obj)
>
> Generic-function approach:
>
> @generic()
> def do_something(obj):
> """Does something fancy with obj"""
>
> @do_something.when("isinstance(obj, basestring)")
> def do_something_with_string(obj)
> ....
>
> @do_something.when("isinstance(obj, int)")
> def do_something_with_int(obj)
> ....
>
> @do_something.when(default)
> def do_something_default(obj)
> ....
>
> As you can see, the generic function approach makes you write even more.
So you triple the length of the code.
> However, the biggest benefit, as I see it, is that these rules can be
> defined anywhere (read: external modules), which basically aids in
> manteinability because you don't need to touch the original module where the
> function is defined when you need to tweak it's behavior. Oh, I should also
So with one call:
jsonify(someobj)
You have to look at code all over place to find out what it really
does? Because there can be some external module which due to the
coolness of generic functions are allowed to define additional rules.
> mention that there's a much smarter algorithm than me taking care of
> balancing the decision tree on the fly so it remains as efficient as
> possible.
Premature optimization.
> Also I should note that you don't *need* to undersand how they work in order
> to *use* them. What can be easier to explain to users than: "To get the JSON
> representation of A do jsonify(A)"? Of course, to actually define new rules
> you have to study them a bit, but come on, I'm not that smart and I can make
> use of them given my limited experience.
Yes and when something goes wrong you have to understand them. And
when someone asks "But Alberto, what DOES jsonfiy(A) do?" that is not
an easy question to answer.
> You too make good use of this when you define rules in soprovider.py to
> jsonify TG_User, etc. How would you have liked to hack on a long list of
I think it is bad use IMHO. The code is:
def jsonify_group(obj):
result = jsonify_sqlobject( obj )
result["users"]= jsonify( [u.user_name for u in obj.users] )
result["permissions"]= jsonify( [p.permission_name for p in
obj.permissions] )
return result
jsonify_group = jsonify.when('isinstance(obj, TG_Group)')(jsonify_group)
Why isn't it instead:
class TG_Group(InheritableSQLObject):
def __json__(self):
result = jsonify_sqlobject( obj )
result["users"]= jsonify( [u.user_name for u in obj.users] )
result["permissions"]= jsonify( [p.permission_name for p in
obj.permissions] )
return result
?
> "elifs" inside an external egg (TurboJSON) making sure it's always up to
> date, doesn't introduce dead branches and doesn't conflict with previous
With a normal simple if-elif dispatch, it wouldn't have to be an
external module. It would be 30 lines of Python code in a file named
jsonify.py. So yeah, I'd definitely prefer to hack in that file over
the complicated dispatch thingy.
> rules? Not to mention that "extenders" of your identity classes can write
> more specific rules, just below their subclasses, to jsonify them in a
> different manner...
Why can't they just override __json__()?
> The bottom line is that I'm not a good judge here, I'm now biased and
> blinded by they're beauty, sorry but I cannot agree with you here... ;) The
> importance generic functions are getting in TG is a plus for me...
Neither am I, but I still like to complain about them. :) They cause
me pain when I try to send utf8 encoded strings through JSON.
--
mvh Björn
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears" group.
To post to this group, send email to turbogears@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/turbogears
-~----------~----~----~----~------~----~------~--~---
