in reply to Refactor method calls or not?

Somewhat offtopic, while I regret that I unfortunately don't have a lot of insight into the Perl solution to this problem, as the (or one of the) resident Common Lisp advocate (or troll, if you wish :-) this is exactly the kind of thing we Lispers like our macro system for. It's fairly easy to write a CL macro that takes the method name and table name and creates an appropriate method, then just call it twice to get the specific methods that you need (and of course, it would still be sitting around if more were needed in the future).

Replies are listed 'Best First'.
Re^2: Refactor method calls or not?
by Aristotle (Chancellor) on Jan 20, 2002 at 14:13 UTC

    If I'm not completely misunderstanding you, that's what could be done with closures in Perl - as mentioned in the first reply on this node by tadman++.

    Makeshifts last the longest.

      It's not exactly the same. For example, there would be no need to go through any contortions for dispatching and so forth. Two calls to the macro would create two normal functions called add_company and add_financial_data, which one would then just use as usual.

      E.g. the Lisp code might look something like this (first the macro is defined, then it is called twice to create the methods, then a couple of calls to the methods).:

      (defmacro make-add-method (method-name table-name) `(defmethod ,method-name ((self my-class) data) (let ((returned-data (generic-insert self data ,table-name))) (unless (check-error self) (commit (database-handle self))) returned-data))) (make-add-method 'add-company "company") (make-add-method 'add-financial-diary "financialDiary") (add-company my-object company-data) (add-financial-diary my-object financial-data)

      The macro does indeed work something like the method of using closures in the previous node - it takes a template for the code that we want (the form following the backquote) and fills in the parts that we want to vary (the forms introduced by ,). There's no need for any of the dispatching contortions, though; it's just as though we typed in the methods ourselves. While Lisp macros are great for many more things than this, they work well for this sort of thing as well, where pieces of code have very similar form, which can then be easily and naturally abstracted out.

        Ohhh duh - I should have read his code closer :-). I think tilly's code example is nearly exactly what you want. Granted, it is indeed not quite as effortless as the macro in LISP and definitely less pretty.

        Makeshifts last the longest.