quick question... Hunchentoot recently (?) moved to a more OO model, correct? I'm just curious... since lambda expressions, closures, macros, and other lisp constructs are often considered 'better' than CLOS (less verbose, less overhead), what made Edi decide to move to the more OO design? Surely it wasn't just popular demand. ;-)
Hmmm. I'm not sure those things are "often considered 'better'" except perhaps by Paul Graham. Anyway, the current architecture, as I understand it, is designed to be extensible in various ways. To build that level of extensibility using closures, etc. you would end up implementing something like CLOS.
-Peter
On Wed, Aug 12, 2009 at 6:45 AM, Jonathon McKitrickjmckitrick@gmail.com wrote:
quick question... Hunchentoot recently (?) moved to a more OO model, correct? I'm just curious... since lambda expressions, closures, macros, and other lisp constructs are often considered 'better' than CLOS (less verbose, less overhead), what made Edi decide to move to the more OO design? Surely it wasn't just popular demand. ;-)
--
Jonathon McKitrick http://moltencopper.com
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
Thanks Peter, that's basically the same answer I would have given... :)
On Wed, Aug 12, 2009 at 3:50 PM, Peter Seibelpeter@gigamonkeys.com wrote:
Hmmm. I'm not sure those things are "often considered 'better'" except perhaps by Paul Graham. Anyway, the current architecture, as I understand it, is designed to be extensible in various ways. To build that level of extensibility using closures, etc. you would end up implementing something like CLOS.
-Peter
On Wed, Aug 12, 2009 at 6:45 AM, Jonathon McKitrickjmckitrick@gmail.com wrote:
quick question... Hunchentoot recently (?) moved to a more OO model, correct? I'm just curious... since lambda expressions, closures, macros, and other lisp constructs are often considered 'better' than CLOS (less verbose, less overhead), what made Edi decide to move to the more OO design? Surely it wasn't just popular demand. ;-)
--
Jonathon McKitrick http://moltencopper.com
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
-- Peter Seibel http://www.codersatwork.com/ http://www.gigamonkeys.com/blog/
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
I admit, I've been caught up in the On Lisp mentality lately. It seems intriguing, especially because CLOS can be so verbose, and macros seem to work more naturally with closures, from what I have learned.
So the best answer here is CLOS is the best way to add extensibility to Hunchentoot, correct?
On Wed, Aug 12, 2009 at 11:27 AM, Edi Weitzedi@agharta.de wrote:
Thanks Peter, that's basically the same answer I would have given... :)
On Wed, Aug 12, 2009 at 3:50 PM, Peter Seibelpeter@gigamonkeys.com wrote:
Hmmm. I'm not sure those things are "often considered 'better'" except perhaps by Paul Graham. Anyway, the current architecture, as I understand it, is designed to be extensible in various ways. To build that level of extensibility using closures, etc. you would end up implementing something like CLOS.
-Peter
On Wed, Aug 12, 2009 at 6:45 AM, Jonathon McKitrickjmckitrick@gmail.com wrote:
quick question... Hunchentoot recently (?) moved to a more OO model, correct? I'm just curious... since lambda expressions, closures, macros, and other lisp constructs are often considered 'better' than CLOS (less verbose, less overhead), what made Edi decide to move to the more OO design? Surely it wasn't just popular demand. ;-)
--
Jonathon McKitrick http://moltencopper.com
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
-- Peter Seibel http://www.codersatwork.com/ http://www.gigamonkeys.com/blog/
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
-
Edi Weitz -
Jonathon McKitrick -
Peter Seibel