Hi all -
Recently, I have been working on a set of date CLOS objects to mimic
python's datetime library in common lisp. I would like to define a
comparison operator to specialize the comparison operator "<" to work
on my objects, but my attempts give the following error in sbcl:
<BEGIN>
STYLE-WARNING: implicitly creating new generic function <
debugger invoked on a SB-INT:SIMPLE-PROGRAM-ERROR in thread
#<THREAD "initial thread" {A7B9341}>:
< already names an ordinary function or a macro.
Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
0: [ABORT] Exit debugger, returning to top level.
(SB-PCL::GENERIC-CLOBBERS-FUNCTION <)
<END>
The code that produces this error:
<BEGIN>
(defmethod < (&rest (this date))
t)
<END>
It occurred to me that I don't know when I can and can't generally
specialize a function such as <, and what restrictions apply. Where do
I look this up? Also, the specific problem I am solving (comparison
of objects) is so common that I am wondering if there are solutions out
there I could look at.
Any advice will be appreciated.
Thanks
Andrew
You can reach me directly using my first name at my domain.
······@andrewschein.com writes:
> Hi all -
>
> Recently, I have been working on a set of date CLOS objects to mimic
> python's datetime library in common lisp. I would like to define a
> comparison operator to specialize the comparison operator "<" to work
> on my objects, but my attempts give the following error in sbcl:
See below for information on why you can't specialize on <.
You can accomplish what you want to do, but you can't do it with the <
symbol in the COMMON-LISP package. The most straightforward way to do
this is to shadow < in your package:
(defpackage :my-datetime
(:use :cl)
(:shadow :<))
(in-package :my-datetime)
(defclass my-datetime-class ()
())
(defgeneric < (first &rest rest))
(defmethod < ((first number) &rest rest)
(apply #'cl:< (cons first rest)))
(defmethod < ((first my-datetime-class) &rest rest)
;; do your thing here
'special-result
)
(defpackage :foo
(:shadowing-import-from :my-datetime #:<)
(:use :cl))
(in-package :foo)
FOO 40 > (< (make-instance 'my-datetime::my-datetime-class) 3)
SPECIAL-RESULT
FOO 41 > (< 3 4)
T
Now anyone can use this package and shadowing-import your specialized
< operator. Any comparisons of numbers will be delegated to the
standard < operator and comparisons of time will go to your date-time
functions.
Personally, though, I think a better and more idiomatic solution is to
define a set of specific time comparison operators, like time<, time>,
time=, etc.
> <BEGIN>
> STYLE-WARNING: implicitly creating new generic function <
>
> debugger invoked on a SB-INT:SIMPLE-PROGRAM-ERROR in thread
> #<THREAD "initial thread" {A7B9341}>:
> < already names an ordinary function or a macro.
>
> Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
>
> restarts (invokable by number or by possibly-abbreviated name):
> 0: [ABORT] Exit debugger, returning to top level.
>
> (SB-PCL::GENERIC-CLOBBERS-FUNCTION <)
> <END>
>
> The code that produces this error:
> <BEGIN>
> (defmethod < (&rest (this date))
> t)
> <END>
>
> It occurred to me that I don't know when I can and can't generally
> specialize a function such as <, and what restrictions apply.
You can only specialize a function that is defined to be a generic
function ("generic" in the CLOS sense, not in the sense of +, REMOVE,
or <, which adapt to the types of their arguments but are not CLOS
generic functions).
So this is valid:
(defgeneric foo (bar baz))
(defmethod foo ((bar integer) baz)
...)
but this is not:
(defun + (bar baz)
(defmethod + ((bar integer) (baz integer))
...)
because + is just a regular function.
In article <··············@bertrand.local>,
Bill Atkins <····························@gmail.com> wrote:
> ······@andrewschein.com writes:
>
> > Hi all -
> >
> > Recently, I have been working on a set of date CLOS objects to mimic
> > python's datetime library in common lisp. I would like to define a
> > comparison operator to specialize the comparison operator "<" to work
> > on my objects, but my attempts give the following error in sbcl:
>
> See below for information on why you can't specialize on <.
>
> You can accomplish what you want to do, but you can't do it with the <
> symbol in the COMMON-LISP package. The most straightforward way to do
> this is to shadow < in your package:
>
> (defpackage :my-datetime
> (:use :cl)
> (:shadow :<))
> (in-package :my-datetime)
>
> (defclass my-datetime-class ()
> ())
>
> (defgeneric < (first &rest rest))
> (defmethod < ((first number) &rest rest)
> (apply #'cl:< (cons first rest)))
You don't need to use CONS. (apply #'cl:< first rest) will work just
fine.
> (defmethod < ((first my-datetime-class) &rest rest)
> ;; do your thing here
> 'special-result
> )
>
> (defpackage :foo
> (:shadowing-import-from :my-datetime #:<)
> (:use :cl))
> (in-package :foo)
>
> FOO 40 > (< (make-instance 'my-datetime::my-datetime-class) 3)
> SPECIAL-RESULT
>
> FOO 41 > (< 3 4)
> T
>
> Now anyone can use this package and shadowing-import your specialized
> < operator. Any comparisons of numbers will be delegated to the
> standard < operator and comparisons of time will go to your date-time
> functions.
>
> Personally, though, I think a better and more idiomatic solution is to
> define a set of specific time comparison operators, like time<, time>,
> time=, etc.
I agree. Using a function that looks like the built-in function is
likely to be confusing, since it becomes difficult to tell visually when
the standard function is being used versus your redefinition. Also,
your function won't be used by any other functions that do comparisons,
unless you shadow them as well. For instance, you won't be able to do:
(sort list-of-dates)
you'll have to write:
(sort list-of-date :test #'<)
or defun your own SORT function whose :TEST argument defaults to your <
function instead of the standard one and then calls the standard SORT.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
On Sweetmorn, The Aftermath 59, 3172 YOLD, Barry Margolin wrote:
>> Now anyone can use this package and shadowing-import your specialized
>> < operator. Any comparisons of numbers will be delegated to the
>> standard < operator and comparisons of time will go to your date-time
>> functions.
>>
>> Personally, though, I think a better and more idiomatic solution is to
>> define a set of specific time comparison operators, like time<, time>,
>> time=, etc.
>
> I agree. Using a function that looks like the built-in function is
> likely to be confusing, since it becomes difficult to tell visually when
> the standard function is being used versus your redefinition. Also,
> your function won't be used by any other functions that do comparisons,
> unless you shadow them as well. For instance, you won't be able to do:
OTOH, that's one of two things I like in Python (second one are
generators). Duck typing. Many libraries' data types are objects
that quack like an iterable, dict or overload attribute access and
with just a handful of language construction (for ... in ...,
attribute access, list comprehensions / generator expressions...). I
don't have to think about which of umpteen mapping functions should I
use or how do I compare one DateTime to another. And if my objects
quack as if they were less or greater than each other, I can safely
use all build-in and library functions that operate on objects by
comparing them for free. Same for quacking like a dict or iterable,
for attribute access, etc, etc, etc.
--
__ Maciek Pasternacki <·······@japhy.fnord.org> [ http://japhy.fnord.org/ ]
`| _ |_\ / { ...that's alright. I was having a bad dream.
,|{-}|}| }\/ I was dreaming about a joke with no punchline... }
\/ |____/ ( David Lynch ) -><-
On Sweetmorn, The Aftermath 64, 3172 YOLD, Rainer Joswig wrote:
>>>> Now anyone can use this package and shadowing-import your specialized
>>>> < operator. Any comparisons of numbers will be delegated to the
>>>> standard < operator and comparisons of time will go to your date-time
>>>> functions.
>>>>
>>>> Personally, though, I think a better and more idiomatic solution is to
>>>> define a set of specific time comparison operators, like time<, time>,
>>>> time=, etc.
>>>
>>> I agree. Using a function that looks like the built-in function is
>>> likely to be confusing, since it becomes difficult to tell visually when
>>> the standard function is being used versus your redefinition. Also,
>>> your function won't be used by any other functions that do comparisons,
>>> unless you shadow them as well. For instance, you won't be able to do:
>>
>> OTOH, that's one of two things I like in Python (second one are
>> generators). Duck typing. Many libraries' data types are objects
>> that quack like an iterable, dict or overload attribute access and
>> with just a handful of language construction (for ... in ...,
>> attribute access, list comprehensions / generator expressions...). I
>> don't have to think about which of umpteen mapping functions should I
>> use or how do I compare one DateTime to another. And if my objects
>> quack as if they were less or greater than each other, I can safely
>> use all build-in and library functions that operate on objects by
>> comparing them for free. Same for quacking like a dict or iterable,
>> for attribute access, etc, etc, etc.
>
> You get the same in CLOS-based libraries. There is not much CLOS-using
> stuff in ANSI CL, but most Lisp systems already come with some
> CLOS-based libraries or CLOS-based implementations.
>
> Many CL implementations are using CLOS for example to implement streams,
> windows, error handling and other things.
Yup, I do know CLOS and I use it. My problem is that CL doesn't ;)
comparison, iteration, element access and such don't have standard
CLOS-based API. I know I can invent some, since most standard types
are also classes and can be specialized on, but I was talking about
plain ANSI.
But your comment led mi to thinking about generic protocol for basic
operations. It would be divided into user's and implementor's
interface. User's interface would give means to iteration, element
access etc. facilities and implementor's interface would be generic
functions that should be specialized on in order to quack like
something. For starters, it could look like this:
* Element access
** User and implementor interface:
- Generic (ELEMENT object key) => OBJECT
- Generic ((SETF ELEMENT) new-value object key)
- General element access (with methods for e.g. nth, aref, hashref,
assoc, getprop).
* Iteration and sequences
Basic object would be an iterator function which yields consecutive
elements of an iterable, signalling END-OF-ITERATION condition when
elements end.
An iterable is an object for which an iterator can be defined.
** Implementor interface
- Condition END-OF-ITERATION
- Generic (ITERATOR object) => function
- Returns an iterator function for an object.
For objects that can be iterated multiple ways (e.g. files --
iterators can return characters, bytes, lines of text or Lisp forms)
there can be multiple functions returning different iterators -- an
iterator itself is an iterable.
** User interface
*** Basic interface
- Generic (IMAP iterable function) => iterator
- Returns iterator that FUNCALLs function on consecutive elements of iterable.
- Generic (IMAP* iterable function) => iterator
- Ditto, but APPLY'es elements to function
*** Utility interface
- Function (IDISCARD iterable) => NIL
- Function (ILIST iterable) => LIST
- Function (IARRAY iterable) => ARRAY
- Function (ISTRING iterable) => STRING
- Possibly more
- Runs over the iterator, returns respective type of sequence (or
just discards return values and returns NIL).
- Function (IZIP &rest iterables) => iterator
- Returns an iterator that yields a list of values of given
iterables (e.g. (IZIP '(A B C) '(D E F) '(G H I))
=> (A D G);(B E H);(C F I))
- Macro (IDO (variable iterable) &body body)
- Iterates BODY with VARIABLE bound to consecutive ITERABLE values.
- Macro (IDO* (variable iterable) &body body)
- Ditto, but variable can be a list and it's given to DESCRUCTURING-BIND.
* Operator overloading
** User and implementor interface
- Generic function (OVERLOADED op &rest args) => RESULT
- Specializes OP with (EQL) on standard function to apply
OVERLOADED-OP generic to ARGS, e.g.:
(defmethod overloaded ((op (eql #'<)) &rest args)
(apply #'overloaded-< args))
(defmethod overloaded-< (a b)
(funcall #'< a b))
(defmethod overloaded-< ((a string) (b string))
(funcall #'string< a b))
Does it make sense? Performance-wise it surely doesn't, but
readability- and elegance-wise? What more patterns can be abstracted
out this way?
> See the attached png file for the subclasses of the mixin
> HCI:HARDCOPY-DEVICE-MIXIN in Genera.
Well, I see just a greeting screen...
--
__ Maciek Pasternacki <·······@japhy.fnord.org> [ http://japhy.fnord.org/ ]
`| _ |_\ / { 2.718281828459045235360287471352662497757247093699959574966967
,|{-}|}| }\/ 62772407663035354759457138217852516642742746639193200305992181741
\/ |____/ 359662904357290033429526059563073813232862794349076... ( e ) -><-
······@andrewschein.com writes:
> Recently, I have been working on a set of date CLOS objects to mimic
> python's datetime library in common lisp. I would like to define a
> comparison operator to specialize the comparison operator "<" to work
> on my objects, but my attempts give the following error in sbcl:
> [...]
> It occurred to me that I don't know when I can and can't generally
> specialize a function such as <, and what restrictions apply. Where do
> I look this up? Also, the specific problem I am solving (comparison
> of objects) is so common that I am wondering if there are solutions out
> there I could look at.
Read the CL reference. For any operator, it indicates the type of operator:
Special Operator
Macro
Function
Generic Function
The Special Operators, the Macros and the Function cannot be redefined.
You can add Methods to the Generic Function, but not on standard classes.
See: http://www.lispworks.com/documentation/HyperSpec/Body/11_abab.htm
CL:< is defined as a Function.
You mustn't use CL:<
You can use either a symbol named "<" but from a different package
than CL, or a symbol named differently (still not in the package CL).
(defpackage "MY-OPS" (:use) (:export "<" ">" ...))
(defgeneric my-ops:< (a b))
(defmethod my-ops:< ((a my-class) (b my-class)) ...)
(defmethod my-ops:< ((a t) (b t)) (cl:< a b))
The other is to do like CL does it (eg for strings): write functions
(or generic functions, if you have different kind of dates) named:
DATE<, DATE>, DATE<=, etc...
Unfortunately, cl:< has for signature (&rest numbers), so you cannot
really dispatch a generic function on these arguments: if you define a
generic with the same signature, you can have only one method.
(cl:< 1 2 3 4)
;; vs:
(and (my-ops:< a1 a2) (my-ops:< a2 a3) (my-ops:< a3 a4))
You could write a function my-ops:< with this signature, and call from
it either cl:< or date< or whatever, depending on the type of the
arguments given.
(defun my-ops:< (&rest args)
(cond ((every (function numberp) args) (apply (function cl:<) args))
((some (function datep) args) (apply (function date<) args))
((some (function stringp) args) (apply (function string<) args))
...
(t (error "Type of arguments incompatible with my-ops:<"))))
Then you could shadow cl:< and import my-ops:< and let normal code go
thru my-ops:<:
(shadow '<)
(import 'my-ops:<)
(cond ((< 1 2) '(yes reals))
((< "abc" "xyz") '(yes strings))
((< yesterday today) '(yes dates))
...)
This is rather messy, and not very useful. The best solution is to
define functions named DATE< DATE> DATE<= etc.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Until real software engineering is developed, the next best practice
is to develop with a dynamic system that has extreme late binding in
all aspects. The first system to really do this in an important way
is Lisp. -- Alan Kay
Pascal Bourguignon ¼g¹D¡G
> Unfortunately, cl:< has for signature (&rest numbers), so you cannot
> really dispatch a generic function on these arguments: if you define a
> generic with the same signature, you can have only one method.
> Then you could shadow cl:< and import my-ops:< and let normal code go
May I ask what does shadow mean??
<············@gmail.com> schrieb im Newsbeitrag ·····························@16g2000cwy.googlegroups.com...
Pascal Bourguignon ¼g¹D¡G
> Unfortunately, cl:< has for signature (&rest numbers), so you cannot
> really dispatch a generic function on these arguments: if you define a
> generic with the same signature, you can have only one method.
> Then you could shadow cl:< and import my-ops:< and let normal code go
May I ask what does shadow mean??
Hi,
serious answer: read
http://www.flownet.com/gat/packages.pdf
Andreas
Andreas Thiele ¼g¹D¡G
> <············@gmail.com> schrieb im Newsbeitrag ·····························@16g2000cwy.googlegroups.com...
> serious answer: read
>
> http://www.flownet.com/gat/packages.pdf
>
> Andreas
Thanks for the link, but when I tried the first code with SBCL.
? (make-package :bob)
#<Package "BOB">
? (make-package :jane)
#<Package "JANE">
? (in-package bob)
#<Package "BOB">
? (defun foo () "This is Bob's foo")
I got an error in defun foo
And the command of in-package, I suppose it's :bob (with a : ), not
bob.
* (in-package :bob)
#<COMMON-LISP:PACKAGE "BOB">
* (defun foo () "This is Bob's foo")
; in: DEFUN FOO
; (BOB::DEFUN BOB::FOO NIL "This is Bob's foo")
;
; caught COMMON-LISP:STYLE-WARNING:
; undefined function: DEFUN
;
; caught COMMON-LISP:WARNING:
; undefined variable: FOO
;
; caught COMMON-LISP:WARNING:
; This variable is undefined:
; FOO
;
; caught COMMON-LISP:STYLE-WARNING:
; This function is undefined:
; DEFUN
;
; compilation unit finished
; caught 2 WARNING conditions
; caught 2 STYLE-WARNING conditions
debugger invoked on a COMMON-LISP:UNBOUND-VARIABLE: The variable FOO is
unbound.
Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
0: [ABORT] Exit debugger, returning to top level.
And after reading the whole document, I think the idea of shadow is
to define a symbol with a higher priority when in conflict, is it
right?
·············@gmail.com" <············@gmail.com> writes:
> Andreas Thiele �g�D�G
>
> > serious answer: read
> >
> > http://www.flownet.com/gat/packages.pdf
> >
> > Andreas
> Thanks for the link, but when I tried the first code with SBCL.
>
> ? (make-package :bob)
> #<Package "BOB">
> ? (make-package :jane)
> #<Package "JANE">
> ? (in-package bob)
> #<Package "BOB">
> ? (defun foo () "This is Bob's foo")
>
> I got an error in defun foo
> And the command of in-package, I suppose it's :bob (with a : ), not
> bob.
No, that's not the case.
According to the specification, the default value for the :USE
argument to MAKE-PACKAGE is implementation-dependent. MCL puts the
COMMON-LISP package in the default list, and SBCL does not.
The only portable way to get a predictable package USE list is to
specify it explicitly:
? (make-package :bob :use '(common-lisp))
Here is what various Lisps show for this code:
(format t "~A ~A~%~A~%"
(lisp-implementation-type)
(lisp-implementation-version)
(package-use-list (make-package (gensym))))
CLISP 2.34 (2005-07-20) (built 3330966858) (memory 3330967026)
(#<PACKAGE COMMON-LISP>)
CMU Common Lisp 19a
(#<The COMMON-LISP package>)
International Allegro CL Trial Edition 7.0 [Linux (x86)] (Aug 4, 2005
16:11)
(#<The COMMON-LISP package>)
LispWorks Personal Edition 4.4.5
(#<PACKAGE COMMON-LISP> #<PACKAGE LISPWORKS>
#<PACKAGE HARLEQUIN-COMMON-LISP>)
SBCL 1.0.0.21
NIL
See also:
http://www.lispworks.com/documentation/HyperSpec/Body/f_mk_pkg.htm
Zach
·············@gmail.com" <············@gmail.com> writes:
> Pascal Bourguignon �g�D�G
> > Unfortunately, cl:< has for signature (&rest numbers), so you cannot
> > really dispatch a generic function on these arguments: if you define a
> > generic with the same signature, you can have only one method.
> > Then you could shadow cl:< and import my-ops:< and let normal code go
> May I ask what does shadow mean??
http://www.lispworks.com/documentation/HyperSpec/Body/11_.htm
and most specifically
http://www.lispworks.com/documentation/HyperSpec/Body/11_aabe.htm
http://www.lispworks.com/documentation/HyperSpec/Body/f_shadow.htm#shadow
--
Thomas A. Russ, USC/Information Sciences Institute
I have the same problem with the method length in a class for sets.
Length is a natural name for a method, but overwrite a builtin
function. I tried set-length, but i think that the use of the class in
the method name is a un-OOP solution.
The Pascal Bourguignon is elegant, but add to much work for a trivial
operation (create a new methdo), so
I decided to add an * symbol to all the method with name clash against
builtin functions.
PS: Sorry for the bad english.
Pascal Bourguignon escreveu:
> ······@andrewschein.com writes:
> > Recently, I have been working on a set of date CLOS objects to mimic
> > python's datetime library in common lisp. I would like to define a
> > comparison operator to specialize the comparison operator "<" to work
> > on my objects, but my attempts give the following error in sbcl:
> > [...]
> > It occurred to me that I don't know when I can and can't generally
> > specialize a function such as <, and what restrictions apply. Where do
> > I look this up? Also, the specific problem I am solving (comparison
> > of objects) is so common that I am wondering if there are solutions out
> > there I could look at.
>
> Read the CL reference. For any operator, it indicates the type of operator:
>
> Special Operator
> Macro
> Function
> Generic Function
>
> The Special Operators, the Macros and the Function cannot be redefined.
> You can add Methods to the Generic Function, but not on standard classes.
> See: http://www.lispworks.com/documentation/HyperSpec/Body/11_abab.htm
>
> CL:< is defined as a Function.
>
> You mustn't use CL:<
>
> You can use either a symbol named "<" but from a different package
> than CL, or a symbol named differently (still not in the package CL).
>
> (defpackage "MY-OPS" (:use) (:export "<" ">" ...))
> (defgeneric my-ops:< (a b))
> (defmethod my-ops:< ((a my-class) (b my-class)) ...)
> (defmethod my-ops:< ((a t) (b t)) (cl:< a b))
>
>
> The other is to do like CL does it (eg for strings): write functions
> (or generic functions, if you have different kind of dates) named:
> DATE<, DATE>, DATE<=, etc...
>
>
>
>
>
> Unfortunately, cl:< has for signature (&rest numbers), so you cannot
> really dispatch a generic function on these arguments: if you define a
> generic with the same signature, you can have only one method.
>
> (cl:< 1 2 3 4)
>
> ;; vs:
>
> (and (my-ops:< a1 a2) (my-ops:< a2 a3) (my-ops:< a3 a4))
>
> You could write a function my-ops:< with this signature, and call from
> it either cl:< or date< or whatever, depending on the type of the
> arguments given.
>
> (defun my-ops:< (&rest args)
> (cond ((every (function numberp) args) (apply (function cl:<) args))
> ((some (function datep) args) (apply (function date<) args))
> ((some (function stringp) args) (apply (function string<) args))
> ...
> (t (error "Type of arguments incompatible with my-ops:<"))))
>
> Then you could shadow cl:< and import my-ops:< and let normal code go
> thru my-ops:<:
>
> (shadow '<)
> (import 'my-ops:<)
>
> (cond ((< 1 2) '(yes reals))
> ((< "abc" "xyz") '(yes strings))
> ((< yesterday today) '(yes dates))
> ...)
>
> This is rather messy, and not very useful. The best solution is to
> define functions named DATE< DATE> DATE<= etc.
>
> --
> __Pascal Bourguignon__ http://www.informatimago.com/
> Until real software engineering is developed, the next best practice
> is to develop with a dynamic system that has extreme late binding in
> all aspects. The first system to really do this in an important way
> is Lisp. -- Alan Kay
"Leonardo Varuzza" <·······@gmail.com> writes:
> I have the same problem with the method length in a class for sets.
> Length is a natural name for a method, but overwrite a builtin
> function. I tried set-length, but i think that the use of the class in
> the method name is a un-OOP solution.
>
> Pascal Bourguignon's solution is elegant, but add to much work for a trivial
> operation (create a new methdo), so
> I decided to add an * symbol to all the method with name clash against
> builtin functions.
Yes, the easiest is just to use a different name.
LENGTH* is good.
Also: amplitude, area, at long last, bigness, body, breadth, bulk,
caliber, clearance, compass, completely, coverage, deep space, depth,
depths of space, diameter, dimension, dimensions, distance,
divergence, duration, eventually, exhaustively, expanse, expansion,
extension, extensively, extent, farness, finally, fully, gauge, girth,
greatness, height, in detail, infinity, interminably, largeness,
leeway, light-years, magnitude, margin, mass, measure, measurement,
mileage, orbit, panorama, parsecs, period, perspective, piece,
proportion, proportions, purview, radius, range, reach, realm,
remoteness, scale, scope, separation, size, space, span, spread,
stretch, stride, term, thoroughly, ultimately, volume, way, ways,
width.
(Thanks to thesauruses).
Also: COMPRIMENTO, LONGUEUR, TAMA�O, etc...
--
__Pascal Bourguignon__ http://www.informatimago.com/
HEALTH WARNING: Care should be taken when lifting this product,
since its mass, and thus its weight, is dependent on its velocity
relative to the user.
"Leonardo Varuzza" <·······@gmail.com> writes:
> I have the same problem with the method length in a class for sets.
> Length is a natural name for a method, but overwrite a builtin
> function. I tried set-length, but i think that the use of the class in
> the method name is a un-OOP solution.
Yes, but fortunately, SIZE is not taken.
Nor is CARDINALITY.
--
Thomas A. Russ, USC/Information Sciences Institute
······@andrewschein.com wrote:
> It occurred to me that I don't know when I can and can't generally
> specialize a function such as <, and what restrictions apply. Where do
> I look this up? Also, the specific problem I am solving (comparison
> of objects) is so common that I am wondering if there are solutions out
> there I could look at.
You can either take a look at the HyperSpec, or find this out
interactively. Try, for example, (class-of #'>) and compare with
(class-of #'print-object). Or try (describe '>) and compare with
(describe 'print-object).
Another way is to call (typep #'> 'generic-function) - compare this to
(typep #'print-object 'generic-function)
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/