[cells-devel] Added an eval-now! to defmodel to suppress SBCL warnings
SBCL kept bugging me with style-warnings when compiling defmd/defmodels for the first time. Wrapping the defclass part of defmodel in an eval-now! fixes it nicely: ; ------- defclass --------------- (^slot-value ,model ',',slotname) (eval-now! ;; suppress style warning in SBCL, ph (prog1 (defclass ,class ,(or directsupers '(model-object)) ;; now we can def the class I committed that to CVS today. Lemme know whether anything breaks. Peter
Peter Hildebrandt wrote:
SBCL kept bugging me with style-warnings when compiling defmd/defmodels for the first time. Wrapping the defclass part of defmodel in an eval-now! fixes it nicely:
; ------- defclass --------------- (^slot-value ,model ',',slotname) (eval-now! ;; suppress style warning in SBCL, ph (prog1 (defclass ,class ,(or directsupers '(model-object)) ;; now we can def the class
I committed that to CVS today. Lemme know whether anything breaks.
Cool, I have been meaning to track that down, I get it, too, with ACL. I believe I reintroduced relativley recently when I casually switched to prog1 to get the class returned by defmodel, instead of using progn and then ending with find-class on the new class, just cuz prog1 seemed more elegant. Probably a better fix would be to refactor so any (^macros) (which is where I get my warnings, when they appear in rules supplied as defaults with the class definition) are defined first so they will be available: (progn <define macros> (prog1 <define class> <define methods on class)) As it is, I believe (not checking) I have one helper macro that does it all for a slot, so has the problem of needing to appear both before and after the defclass. oops. Another thing I want to do is change those (^macros) to be ^macros (symbol macros expanding to the same thing) now that they are zero-argument macros -- they once were much different beasts. Anyway, I have an app to write, this interim patch is fine. Thx, kt ps. What /were/ the style warnings? k
Probably a better fix would be to refactor so any (^macros) (which is where I get my warnings, when they appear in rules supplied as defaults with the class definition) are defined first so they will be available:
(progn <define macros> (prog1 <define class> <define methods on class))
Makes sense -- but I am quite busy, too, at the moment, so this will have to wait :-)
Another thing I want to do is change those (^macros) to be ^macros (symbol macros expanding to the same thing) now that they are zero-argument macros
Thought about that, too. But ...
Anyway, I have an app to write, this interim patch is fine.
exactly :-)
ps. What /were/ the style warnings? k
Real warnings, actually they were, one per slot plus one for the shared-initialize, telling me that there are methods specializing on an unknown class. I tend to take those seriously, because usually they point to a typo somewhere. So does SLIME by highlighting the defmd form in red everytime I compile for the first time. Now I get style warnings for redefining stuff (probably the eval-now! executes stuff twice), but it is much easier to ignore those than the real warnings about an undefined class. Peter
On Wed, May 21, 2008 at 07:36:12AM -0400, Ken Tilton wrote:
Another thing I want to do is change those (^macros) to be ^macros (symbol macros expanding to the same thing) now that they are zero-argument macros -- they once were much different beasts.
My two cents on this: I like the ^accessor style, but don't always use "self", e.g. in a method with two objects of the same time. Any chance you could make the macro take an optional argument and use it instead of "self" if supplied? -- L
participants (3)
-
Ken Tilton -
Larry Clapp -
Peter Hildebrandt