News for the handful of people interested in gfs.
Below is a sample trace of the gf implementation.
Dispatch is wholly deterministic; you never need prefer-method. There
is no need to specify a dispatch function, though dispatch
customization is available if you want it. The default dispatch
function matches methods by using a sequence of matcher functions,
finding methods whose formal parameter constraints match the supplied
argument values. The standard matchers, in order from least to most
specific, are: wildcard (any value matches), type (class or isa?),
equal (the argument equals a declared values), and test (the argument
satisfies a uder-supplied predicate). A second premade matcher
sequence provides dispatching on isa? with user-supplied hierarchies,
as well.
In the scope in which a generic function is applied, next-method is
always bound to the next applicable method in a total ordering of
applicable methods for the arguments supplied (see the first
java.lang.Integer method below for an example of how to use next-
method). applicable-methods is always bound to a function that returns
a list of applicable methods, ordered from most- to least-specific;
next-method is equal to (first (applicable-methods)).
As in CLOS, if you call define-method on an unbound name, then define-
generic-function is called for you with the most common arguments. You
only need to call define-generic-function if you want to do something
more esoteric, like customizing dispatch.
This iteration is more complete than the previous one; for example,
next-method is implemented. :before and :after methods are still not
implemented. You can supply your own sequence of matchers, but you
can't yet replace the default dispatching function that uses them to
find and order applicable methods.
No caching of method orderings is performed at present, and I'm sure a
critical eye could find other things to improve in the performance. gf
calling currently takes something like ten times as long as a MultiFn
call in the relatively simple cases I've tested, with most of the
extra time going into sorting the applicable methods. Implementing the
sort of method cache that every Common Lisp uses would likely be a big
improvement.
If you want the code, send email to mevins at mac dot com and let me
know; I'll tell you how to get it. It's sort of embedded in the larger
project that it's a part of right now (it uses a few lower-level
utilities that are part of the project), but if there's sufficient
interest I could make it self-contained without too much effort.
user> (define-method add [x y]
(str "don't know how to add these things: "
x " " y))
#<generic-function add>
user> (add 1 2)
"don't know how to add these things: 1 2"
user> (define-method add [[x java.lang.Number]
[y java.lang.Number]]
(+ x y))
#<generic-function add>
user> (add 1 2)
3
user> (define-method add [[x java.lang.Integer]
[y java.lang.Integer]]
(let [result (xg.gf/next-method x y)]
(println "this is the integer version")
result))
#<generic-function add>
user> (add 1 2)
this is the integer version
3
user> (add 1.0 2.0)
3.0
user> (add 1.0 2)
3.0
user> (define-method add [[x java.lang.String]
[y java.lang.String]]
(str x y))
#<generic-function add>
user> (add "foo" "bar")
"foobar"
user> (define-method add [[x java.lang.String]
[y java.lang.Integer]]
(str x y))
#<generic-function add>
user> (add "foo" 3)
"foo3"
user> (add 'foo 'bar)
"don't know how to add these things: foo bar"
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~----------~----~----~----~------~----~------~--~---
