And while I'm at it: why, oh why have you added "*" to those methods? To make people recheck their code's compatibility with new Hunchentoot?
BTW, I like the idea of easy-handlers very much. I've been making similar macros for quite a while, and I wonder: do you plan to add to CL-WHO some machinery to reuse these "function arguments"? I mean, often (at least for me) web page contains a form with action pointing to the same page, and it's rather boring to write (:input :type "text" :name "arg1" :value arg1) etc. Again, I have some macros for that, but rather unpolished.
Dmitri Hrapof wrote:
why, oh why have you added "*" to those methods? To make people recheck their code's compatibility with new Hunchentoot?
To discern them from the underlying accessors. Every function with the * suffix is a convenience interface.
Leslie
Leslie P. Polzer <sky <at> viridian-project.de> writes:
To discern them from the underlying accessors. Every function with the * suffix is a convenience interface.
I understand that, but take, for example (cookie-in name &optional request) where request defaults to *REQUEST*. I think request-uri* could be a default method for the generic function request-uri.
Sincerely yours, Dmitri
Dmitri Hrapof wrote:
I understand that, but take, for example (cookie-in name &optional request) where request defaults to *REQUEST*.
COOKIE-IN doesn't have the * suffix because it doesn't conflict with an accessor name.
I think request-uri* could be a default method for the generic function request-uri.
I don't get what you're aiming for, but surely REQUEST-URI* can never be a method for a generic function named REQUEST-URI (lest you apply some serious MOP hackery maybe).
Leslie
Leslie P. Polzer <sky <at> viridian-project.de> writes:
COOKIE-IN doesn't have the * suffix because it doesn't conflict with an accessor name.
I understand that too ;)
I don't get what you're aiming for, but surely REQUEST-URI* can never be a method for a generic function named REQUEST-URI (lest you apply some serious MOP hackery maybe).
I meant:
why not instead of REQUEST-URI*
use something like:
(defclass request () ((uri))) (defgeneric request-uri (&optional req)) (defmethod request-uri (&optional (req request)) (when (null req) ...
though maybe sacrificing backwards-compatibility is better than writing all that :)
Dmitri Hrapof wrote:
why not instead of REQUEST-URI*
use something like:
(defclass request () ((uri))) (defgeneric request-uri (&optional req)) (defmethod request-uri (&optional (req request)) (when (null req) ...
though maybe sacrificing backwards-compatibility is better than writing all that :)
You would seriously subvert the essential meaning of methods, i.e. being able to dispatch on their arguments.
How would you be able to support a custom subclass of REQUEST wishing to specialize REQUEST-URI (and all the other functions) then?
Leslie
On Thu, May 21, 2009 at 5:18 PM, Leslie P. Polzer sky@viridian-project.de wrote:
You would seriously subvert the essential meaning of methods, i.e. being able to dispatch on their arguments.
Yep, exactly. That was the reason we didn't do it this way.
Yes, it turns out (defmethod request-uri (&optional (req a)) doesn't work as I thought. Should make some new hrARpC dialect ;)
Thank you!
-
Dmitri Hrapof -
Edi Weitz -
Leslie P. Polzer