[hunchentoot-devel] asterisk
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 -- http://www.linkedin.com/in/polzer
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 -- http://www.linkedin.com/in/polzer
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 -- http://www.linkedin.com/in/polzer
Yes, it turns out (defmethod request-uri (&optional (req a)) doesn't work as I thought. Should make some new hrARpC dialect ;) Thank you!
participants (3)
-
Dmitri Hrapof -
Edi Weitz -
Leslie P. Polzer