The claim that
= is less strict than
is not strictly true, strictly speaking.
This finickiness though means that you should always use
= if you're dealing with numbers. If you use
equal, you'll let bad non-numeric
values propagate longer. Catch bad values as early as possible.
The application is really neat and the code is mostly excellent, except for the abundance of anonymous constants.
defsphere is a poor name.
are usually for macros, but this is a normal function.
new-sphere would be better.
intersect is a poor name because it's very similar to
intersection, a Common Lisp function for intersecting
More importantly, this is a good example of code that should be
either data-driven or
object-oriented. Consider what would happen if
we wanted to define a new kind of object, say a cube. We would have
to change the definition of
(defun intersect (s pt xr yr zr) (funcall (typecase s (sphere #'sphere-intersect) (cube #'cube-intersect)) s pt xr yr zr))
That's easy. But where does this definition belong? It clearly
doesn't belong in the sphere definition file any more, nor does it
belong in the cube file. We need a new file where
intersect is defined. That file depends on each of the
object definition files. And every time we define a new kind of
object, we will have to redefine
intersect in this file.
The data-driven and
object-oriented versions turn this dependency
around. In both versions, each object file depends on the file that
intersect method. New object files can be
created freely, without ever changing the