Greetings,
I have created a small set of utilities to make CLOS easy to use and
understand. I also include a tutorial.
Trying to create a class hierarchy that includes both class specific and
instance specific slots (variables) and methods can be tricky. When
creating classes, languages such as Smalltalk automatically create a
corresponding meta-class hierarchy. This makes the creation of class
and instance variables easy and natural. CLOS certainly has the ability
to provide this functionality but the supplied machinery is at too low a
level making it difficult and confusing. This package attempts to
remedy this. (For example, how many times have people asked how they
can get at a class slot without creating an instance?)
The package can be found at:
http://blake.mcbride.name/software/clos-utils/index.html
Blake McBride
·····@mcbride.name
In article <································@supernews.com>,
Blake McBride <·····@mcbride.name> wrote:
> Greetings,
>
> I have created a small set of utilities to make CLOS easy to use and
> understand. I also include a tutorial.
>
> Trying to create a class hierarchy that includes both class specific and
> instance specific slots (variables) and methods can be tricky. When
> creating classes, languages such as Smalltalk automatically create a
> corresponding meta-class hierarchy. This makes the creation of class
> and instance variables easy and natural. CLOS certainly has the ability
> to provide this functionality but the supplied machinery is at too low a
> level making it difficult and confusing. This package attempts to
> remedy this. (For example, how many times have people asked how they
> can get at a class slot without creating an instance?)
>
> The package can be found at:
>
> http://blake.mcbride.name/software/clos-utils/index.html
>
> Blake McBride
> ·····@mcbride.name
Blake, I think you are fighting against the language.
CLOS is not Smalltalk and to make it Smalltalk it takes
quite a bit more work.
I find your claim that your code makes CLOS more user friendly
to be dubious.
Your macro is only a thin layer and does zero error checking.
Hardly user friendly. What the syntax of your DEFCLASS2
is, is also not documented and not checked.
Introducing global variables for each class is bad.
Each of these variables will be declared special,
which can be a source of errors in other places.
I don't want:
(defclass vehicle () ()) and suddenly VEHICLE
is a global special variable.
This affects then code like (defun foo (vehicle) ...)
or other, since the name VEHICLE is declared special.
BAD. Very BAD!
SET-SOMETHING is not the Common LIsp style. It has
replaced by SETF and places long ago. Sure, it is
one more thing to learn, but it gets rid of the
(SET-SOMETHING ...) and replaces it with
setf (something ... ) ...) which then works for
every getter. You would never have to know the SETTER.
SET-SLOT, GET-SLOT is just another macro. It just gets in the
way without adding value. The variables are not speaking.
Compare:
(SLOT-VALUE vehicle-1 'speed)
with
(get-slot vehicle-1 speed)
For slot-value it is clear what a slot-name is and what not.
Your code does not allow for example to use a slot-name
in a variable.
(loop for slot in '(a b c) do (get-slot vehicle-1 slot))
Does not work.
Please don't introduce addtional macros where functions are fine.
With Make-Instance your are also not doing a favor.
(make-instance 'vehicle) vs. (make-instance vehicle) .
Again you are blurring the difference between names
and variables. Common Lisp is not Scheme or Smalltalk.
We use symbols for names. With the added benefit that
the compiler often will generate code that is
faster for (make-instance 'some-symbol) compared
to (make-instance some-variable) because the
symbol is there at compile time and if its a known class
some optimizations might apply. In your style,
it's a variable and the compiler can assume nothing,
because the variable might not have a value at compile time
or because the variable value might be different at runtime.
There are no Instance methods in CLOS and your code
does not introduce them. CLOS methods are not attached
to classes like in many object-oriented languages.
The 'industry standard' for OO has yet to be defined.
Is it Java? Then your code does not get the user
anywhere near that 'industry standard'.
Personally I have never missed per-class meta-class hierarchies.
So, IMHO your code introduces a lot of ways to subvert the usability
of Common Lisp without really adding value.
I would propose either to
a) spend more time on the design and be more careful to not
work against Common Lisp and don't introduce bad practices.
b) better write a introduction by listing the differences
between Common Lisp and your felt OO-Industry-Standard
(which I don't see, btw.) and then help the new
user to adopt the CLOS style. When in France, speak French.
When in Germany speak German.
Sorry for being a bit negative. ;-)
--
http://lispm.dyndns.org/