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 candef 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
-
Ken Tilton -
Larry Clapp -
Peter Hildebrandt