in reply to Re^2: Refactor method calls or not?
in thread Refactor method calls or not?

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.

Replies are listed 'Best First'.
Re^4: Refactor method calls or not?
by Aristotle (Chancellor) on Jan 21, 2002 at 03:56 UTC
    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.

      Indeed, Tilly's node gives essentially the same solution to the problem in Perlish form, but I didn't see it until after I put mine up. (It's also the kind of solution I think it would be easier to think of in Perl if one also knew Lisp - which Tilly does.) Hopefully there's still some value in comparing.

        You can learn an idea in any language that supports it. If it is easier to learn this kind of technique in Lisp, it is because Lisp has a high density of "expert experts". However Perlmonks is not doing too badly on that measure either.

        As for the similarity between the two solutions, they are similar and different. They are conceptually similar in that you institute the idea of code that writes your functions for you. But the ways that they allow you to dynamically generate code are completely unrelated mechanisms, and the difference has implications for memory usage, run-time performance, and flexibility. (The Lisp solution will, all else being equal, use more memory, have better run-time performance (as long as cache-misses are irrelevant), and is more flexible in what you can easily accomplish. Of course all else is not equal...)