On 23/04/2006, at 18:13, BJörn Lindqvist wrote:
>
>> 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.
Yep, for simple things the KISS maxim should be applied.
>
>> 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.
Or use a debugger
>
>> 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.
Ok, and when you have 1500 rules? Or when you wan to change the rules
for a different client's install?
>> 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.
import pdb
>> 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
Actually that example would work by grace of
jsonify.jsonify_explicit, flexibility...
Oh, and you might want to jsonify objects built from classes you
cannot directly modify, like from an C extension. Ok, ok.. you can
wrap that C extension's object and provide the __json__ method
yourself... but I *personally* would favor writing a new rule to
overload a generic function. A matter of taste I guess...
>> "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.
Ok, now you want to distribute your project... with a hacked version
of dependency Y which obliges your users to have Y and Y' on their
systems with the most probably headaches they'll experience.
>> 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__()?
C extension example above.
>> 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.
No problem, I still like to defend them ;)
Alberto
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
