From: jmckitrick
Subject: Better class type compare than typep?
Date: 
Message-ID: <1156372692.322870.76440@75g2000cwc.googlegroups.com>
typep returns T if the class is even derived from the class name being
compared, correct?

How do I test if an object is EXACTLY a specific class, not just
derived from it?

I tried class-of, but I must not be using it correctly.  Note here I'm
not testing for any base class, just a comparison that works.

CL-USER> (defparameter *item* (make-instance
			       'db::<rlg-record>))
*ITEM*

CL-USER> (class-of *item*)
#<STANDARD-CLASS DB::<RLG-RECORD>>

CL-USER> (eq (class-of *item*) 'db::<rlg-record>)
NIL
CL-USER> (eql (class-of *item*) 'db::<rlg-record>)
NIL
CL-USER> (equal (class-of *item*) 'db::<rlg-record>)
NIL
CL-USER>

From: Pascal Costanza
Subject: Re: Better class type compare than typep?
Date: 
Message-ID: <4l44hbF6tl6U1@individual.net>
jmckitrick wrote:
> typep returns T if the class is even derived from the class name being
> compared, correct?
> 
> How do I test if an object is EXACTLY a specific class, not just
> derived from it?
> 
> I tried class-of, but I must not be using it correctly.  Note here I'm
> not testing for any base class, just a comparison that works.
> 
> CL-USER> (defparameter *item* (make-instance
> 			       'db::<rlg-record>))
> *ITEM*
> 
> CL-USER> (class-of *item*)
> #<STANDARD-CLASS DB::<RLG-RECORD>>
> 
> CL-USER> (eq (class-of *item*) 'db::<rlg-record>)
> NIL
> CL-USER> (eql (class-of *item*) 'db::<rlg-record>)
> NIL
> CL-USER> (equal (class-of *item*) 'db::<rlg-record>)
> NIL
> CL-USER>

(class-of something) gives you an object representing the class, not the 
name of the class.

Try (eq (class-of something) (find-class 'some-class)) instead.


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/
From: Ken Tilton
Subject: Re: Better class type compare than typep?
Date: 
Message-ID: <Xd5Hg.59$Pz4.14@newsfe09.lga>
Pascal Costanza wrote:
> jmckitrick wrote:
> 
>> typep returns T if the class is even derived from the class name being
>> compared, correct?
>>
>> How do I test if an object is EXACTLY a specific class, not just
>> derived from it?
>>
>> I tried class-of, but I must not be using it correctly.  Note here I'm
>> not testing for any base class, just a comparison that works.
>>
>> CL-USER> (defparameter *item* (make-instance
>>                    'db::<rlg-record>))
>> *ITEM*
>>
>> CL-USER> (class-of *item*)
>> #<STANDARD-CLASS DB::<RLG-RECORD>>
>>
>> CL-USER> (eq (class-of *item*) 'db::<rlg-record>)
>> NIL
>> CL-USER> (eql (class-of *item*) 'db::<rlg-record>)
>> NIL
>> CL-USER> (equal (class-of *item*) 'db::<rlg-record>)
>> NIL
>> CL-USER>
> 
> 
> (class-of something) gives you an object representing the class, not the 
> name of the class.
> 
> Try (eq (class-of something) (find-class 'some-class)) instead.

For. The. Love. Of. God. Will you never learn?

The newbie thinks (in effect) that instances of subclasses are not (to 
help you (in any sense conceivable)) not instances of the class? And all 
you can do is help with literal synatx?! A-frickin-stonishing. Well, you 
are still a newbie yourself, maybe you have not learned to think at 
higher levels in Lisp.

Speaking of which, WTF was wrong with?:

     (eq (type-of something) 'some-class)

:)

kt

-- 
Cells: http://common-lisp.net/project/cells/

"I'll say I'm losing my grip, and it feels terrific."
    -- Smiling husband to scowling wife, New Yorker cartoon
From: Pascal Costanza
Subject: Re: Better class type compare than typep?
Date: 
Message-ID: <4l53ahF9kktU1@individual.net>
Ken Tilton wrote:
> 
> 
> Pascal Costanza wrote:
>> jmckitrick wrote:
>>
>>> typep returns T if the class is even derived from the class name being
>>> compared, correct?
>>>
>>> How do I test if an object is EXACTLY a specific class, not just
>>> derived from it?
>>>
>>> I tried class-of, but I must not be using it correctly.  Note here I'm
>>> not testing for any base class, just a comparison that works.
>>>
>>> CL-USER> (defparameter *item* (make-instance
>>>                    'db::<rlg-record>))
>>> *ITEM*
>>>
>>> CL-USER> (class-of *item*)
>>> #<STANDARD-CLASS DB::<RLG-RECORD>>
>>>
>>> CL-USER> (eq (class-of *item*) 'db::<rlg-record>)
>>> NIL
>>> CL-USER> (eql (class-of *item*) 'db::<rlg-record>)
>>> NIL
>>> CL-USER> (equal (class-of *item*) 'db::<rlg-record>)
>>> NIL
>>> CL-USER>
>>
>>
>> (class-of something) gives you an object representing the class, not 
>> the name of the class.
>>
>> Try (eq (class-of something) (find-class 'some-class)) instead.
> 
> For. The. Love. Of. God. Will you never learn?
> 
> The newbie thinks (in effect) that instances of subclasses are not (to 
> help you (in any sense conceivable)) not instances of the class? And all 
> you can do is help with literal synatx?! A-frickin-stonishing. Well, you 
> are still a newbie yourself, maybe you have not learned to think at 
> higher levels in Lisp.

"The newbie" already mentioned typep, so was aware of its existence. 
Checking whether an object is a direct instance of a class, instead of 
"just" an instance of a class or any of its subclasses, can be useful in 
some cases. Since "the newbie" didn't say what he wants to achieve, I 
assume that he know what he's doing.

> Speaking of which, WTF was wrong with?:
> 
>     (eq (type-of something) 'some-class)

There's nothing wrong with this.


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/
From: jmckitrick
Subject: Re: Better class type compare than typep?
Date: 
Message-ID: <1156446068.173547.144260@m79g2000cwm.googlegroups.com>
Pascal Costanza wrote:
> Ken Tilton wrote:
> > For. The. Love. Of. God. Will you never learn?
> >
> > The newbie thinks (in effect) that instances of subclasses are not (to
> > help you (in any sense conceivable)) not instances of the class? And all
> > you can do is help with literal synatx?! A-frickin-stonishing. Well, you
> > are still a newbie yourself, maybe you have not learned to think at
> > higher levels in Lisp.

"No flavor's quite so bitter as the taste of one's own shoe." - Primus

> "The newbie" already mentioned typep, so was aware of its existence.
> Checking whether an object is a direct instance of a class, instead of
> "just" an instance of a class or any of its subclasses, can be useful in

Thank you, Pascal.  I may be an idiot, but I'm not stupid.
BTW, your suggestion was exactly what I was looking for.

> some cases. Since "the newbie" didn't say what he wants to achieve, I
> assume that he know what he's doing.

I have an object that should be handled one way *IFF* it is truly a
direct instance of a certain class, not a derivative of said class.

CLHS:
Function CLASS-OF
Syntax:
class-of object => class
Arguments and Values:
object---an object.
class---a class object.
Description:
Returns the class of which the object is a direct instance.
From: Ken Tilton
Subject: Re: Better class type compare than typep?
Date: 
Message-ID: <S3tHg.220$fu5.73@newsfe10.lga>
> Thank you, Pascal.  I may be an idiot, but I'm not stupid.
> BTW, your suggestion was exactly what I was looking for.
...
> I have an object that should be handled one way *IFF* it is truly a
> direct instance of a certain class, not a derivative of said class.

Wow, Pascal, the OP has learned a ton from your help. :)

kt

-- 
Cells: http://common-lisp.net/project/cells/

"I'll say I'm losing my grip, and it feels terrific."
    -- Smiling husband to scowling wife, New Yorker cartoon
From: Jack Unrue
Subject: Re: Better class type compare than typep?
Date: 
Message-ID: <jbqse21obreoknktjeal4q5dnkul0f3aon@4ax.com>
On 24 Aug 2006 12:01:08 -0700, "jmckitrick" <···········@yahoo.com> wrote:
>
> I have an object that should be handled one way *IFF* it is truly a
> direct instance of a certain class, not a derivative of said class.

The following question is absolutely not meant to second-guess
your design, even if it seems to. I'm just really curious. What is
it about implementing a defmethod with an argument specializing on
db::<rlg-record> that doesn't fit your needs?

-- 
Jack Unrue
From: jmckitrick
Subject: Re: Better class type compare than typep?
Date: 
Message-ID: <1156493577.333545.124010@74g2000cwt.googlegroups.com>
Jack Unrue wrote:
> The following question is absolutely not meant to second-guess
> your design, even if it seems to. I'm just really curious. What is
> it about implementing a defmethod with an argument specializing on
> db::<rlg-record> that doesn't fit your needs?

There very well may be a better way to do this, but here goes:

I have a base class and a handful of derived classes, some at a couple
of levels from the base class.  I call a method on an object, which
walks down the tree of methods, toward the most general base class, of
course.  The base class by itself represents a basic test case, with
the most basic functionality and slots the object supports/provides.  I
*could* sub-class it, but I don't really want to right now.  I just
want to check in the method that specializes on it - if the object is
one of *these*, and not *derived* from one of these... this is a test
case, so do a couple of things extra to generate some debug output.
From: Jack Unrue
Subject: Re: Better class type compare than typep?
Date: 
Message-ID: <55aue21238e9vggu4cb7cbh3foveeb3gpp@4ax.com>
On 25 Aug 2006 01:12:57 -0700, "jmckitrick" <···········@yahoo.com> wrote:

> Jack Unrue wrote:
> > The following question is absolutely not meant to second-guess
> > your design, even if it seems to. I'm just really curious. What is
> > it about implementing a defmethod with an argument specializing on
> > db::<rlg-record> that doesn't fit your needs?
> 
> There very well may be a better way to do this, but here goes:
> 
> I have a base class and a handful of derived classes, some at a couple
> of levels from the base class.  I call a method on an object, which
> walks down the tree of methods, toward the most general base class, of
> course.  The base class by itself represents a basic test case, with
> the most basic functionality and slots the object supports/provides.  I
> *could* sub-class it, but I don't really want to right now.  I just
> want to check in the method that specializes on it - if the object is
> one of *these*, and not *derived* from one of these... this is a test
> case, so do a couple of things extra to generate some debug output.

OK, thanks for elaborating!

-- 
Jack Unrue
From: sidney
Subject: Re: Better class type compare than typep?
Date: 
Message-ID: <44eed1d3$0$96210$742ec2ed@news.sonic.net>
jmckitrick wrote, On 25/8/06 8:12 PM:
> if the object is
> one of *these*, and not *derived* from one of these

Why not simply define a slot with an :initform that says which class it is, or
a method that returns a value that says which class it is? You could even put
that in a macro that expands to defclass with the slot added in or expands to
defclass and the defmethod.

 Sidney Markowitz
 ······@sidney.com
From: Jack Unrue
Subject: Re: Better class type compare than typep?
Date: 
Message-ID: <51tse2dvahh378m6mhg4oh2dhq5e074m37@4ax.com>
On Fri, 25 Aug 2006 03:26:23 GMT, Jack Unrue <·······@example.tld> wrote:

> On 24 Aug 2006 12:01:08 -0700, "jmckitrick" <···········@yahoo.com> wrote:
> >
> > I have an object that should be handled one way *IFF* it is truly a
> > direct instance of a certain class, not a derivative of said class.
> 
> The following question is absolutely not meant to second-guess
> your design, even if it seems to. I'm just really curious. What is
> it about implementing a defmethod with an argument specializing on
> db::<rlg-record> that doesn't fit your needs?

Before anybody jumps in and points out that OP didn't want
such code to execute for subclasses, let me just say that there
are plenty of ways for that to happen, and avoiding defmethod
is not a solution. Right?

-- 
Jack Unrue
From: Pascal Costanza
Subject: Re: Better class type compare than typep?
Date: 
Message-ID: <4l7lqbFl2csU1@individual.net>
Jack Unrue wrote:
> On Fri, 25 Aug 2006 03:26:23 GMT, Jack Unrue <·······@example.tld> wrote:
> 
>> On 24 Aug 2006 12:01:08 -0700, "jmckitrick" <···········@yahoo.com> wrote:
>>> I have an object that should be handled one way *IFF* it is truly a
>>> direct instance of a certain class, not a derivative of said class.
>> The following question is absolutely not meant to second-guess
>> your design, even if it seems to. I'm just really curious. What is
>> it about implementing a defmethod with an argument specializing on
>> db::<rlg-record> that doesn't fit your needs?
> 
> Before anybody jumps in and points out that OP didn't want
> such code to execute for subclasses, let me just say that there
> are plenty of ways for that to happen, and avoiding defmethod
> is not a solution. Right?

One of the earlier stages of the CLOS design had a way to "cancel" a 
slot in a subclass so that it's not there in instance even if it would 
otherwise be inherited from a superclass.

While Kiczales et al. worked on the CLOS MOP specification, they were 
experimenting with new specializers (similar to the already existing eql 
specializers). One of them was eq-class which would have done what the 
OP was asking for:

(defmethod foo ((obj (eq-class my-class)))
   ; only applies when obj is a direct instance of my-class
   )

There are actually cases where such a specializer would be useful, and 
it would help a CLOS implementation to generate more efficient code for 
such cases.

Eiffel actually has a feature to "cancel" methods in subclasses.

So what the OP asked for is something that others have thought of 
before. Apparently, there are people who think these things could be useful.

Do you think that eql specializers are useful? Well, they complicate a 
CLOS implementation considerably, and Kiczales has argued for dropping 
them in the end. Indeed, TinyCLOS doesn't have them anymore.

Just because CLOS has a feature doesn't mean that it is the obvious 
right thing to add it to an object system. Just because CLOS doesn't 
have a feature doesn't mean that it is the obvious wrong thing to add it 
to an object system.

Object systems don't grow on trees.


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/
From: Ken Tilton
Subject: Re: Better class type compare than typep?
Date: 
Message-ID: <0rzHg.467$bA1.193@newsfe08.lga>
>>> The following question is absolutely not meant to second-guess
>>> your design, even if it seems to. I'm just really curious. What is
>>> it about implementing a defmethod with an argument specializing on
>>> db::<rlg-record> that doesn't fit your needs?



> There are actually cases where such a specializer would be useful,..

We're waiting. (To hear what those are.)

> So what the OP asked for is something that others have thought of 
> before. Apparently, there are people who think these things could be 
> useful.

Talk about hand-waving. We would not need the entire frickin history of 
programming languages if we knew the functional requirement that 
justifies the OP's request.

C'mon, we either get a good OO design lesson (and the newb gets /real/ 
help) or everyone gets a chance to dance on my grave -- talk about 
win-win! So...

...where's the motivating requirement? The silence is deafening.

kt

-- 
Cells: http://common-lisp.net/project/cells/

"I'll say I'm losing my grip, and it feels terrific."
    -- Smiling husband to scowling wife, New Yorker cartoon
From: Joe Marshall
Subject: Re: Better class type compare than typep?
Date: 
Message-ID: <1156524043.609405.179230@i3g2000cwc.googlegroups.com>
Ken Tilton wrote:
> >>> The following question is absolutely not meant to second-guess
> >>> your design, even if it seems to. I'm just really curious. What is
> >>> it about implementing a defmethod with an argument specializing on
> >>> db::<rlg-record> that doesn't fit your needs?
>
>
>
> > There are actually cases where such a specializer would be useful,..
>
> We're waiting. (To hear what those are.)

Give me a moment!

Ok, I needed an eql-class specializer to handle schema-upgrade in
ChangeSafe:

(defmethod pstore::restore-instance ((class (eql (find-class
'workspace)))
                                     (schema (eql 0))
                                     persistent-store node-id
node-index
                                     init-plist)
  (debug-message 2 "Upgrading schema for workspace.")
  (call-next-method
   class 1 persistent-store node-id node-index
   (list* :added-master-csets 0
          :removed-master-csets 0
          :transitional-added-master-csets 0
          :transitional-removed-master-csets 0
          init-plist)))

Since there is no eql-class specializer, I just used an EQL specializer
with a FIND-CLASS argument.


Although Tiny-CLOS removed EQL specializers, Eli Barzilay put them back
in when he adapted Tiny-CLOS for Swindle.  I think the MIT Scheme SOS
object system, also derived from Tiny-CLOS, has EQL specializers as
well.
From: Ken Tilton
Subject: Re: Better class type compare than typep?
Date: 
Message-ID: <F5HHg.343$ic2.290@newsfe08.lga>
Joe Marshall wrote:
> Ken Tilton wrote:
> 
>>>>>The following question is absolutely not meant to second-guess
>>>>>your design, even if it seems to. I'm just really curious. What is
>>>>>it about implementing a defmethod with an argument specializing on
>>>>>db::<rlg-record> that doesn't fit your needs?
>>
>>
>>
>>>There are actually cases where such a specializer would be useful,..
>>
>>We're waiting. (To hear what those are.)
> 
> 
> Give me a moment!
> 
> Ok, I needed an eql-class specializer to handle schema-upgrade in
> ChangeSafe:

Yeah, and I look for specific type-of somewhere in Cells, where I am 
doing MOPpish stuff. But at the abstraction level that is the MOP, the 
equivalent question is "where do me need an exact match on metaclass?"

kt

-- 
Cells: http://common-lisp.net/project/cells/

"I'll say I'm losing my grip, and it feels terrific."
    -- Smiling husband to scowling wife, New Yorker cartoon
From: Pascal Costanza
Subject: Re: Better class type compare than typep?
Date: 
Message-ID: <4l93nnFqqr2U1@individual.net>
Ken Tilton wrote:
> 
> Joe Marshall wrote:
>> Ken Tilton wrote:
>>
>>>>>> The following question is absolutely not meant to second-guess
>>>>>> your design, even if it seems to. I'm just really curious. What is
>>>>>> it about implementing a defmethod with an argument specializing on
>>>>>> db::<rlg-record> that doesn't fit your needs?
>>>
>>>> There are actually cases where such a specializer would be useful,..
>>>
>>> We're waiting. (To hear what those are.)
>>
>> Give me a moment!
>>
>> Ok, I needed an eql-class specializer to handle schema-upgrade in
>> ChangeSafe:
> 
> Yeah, and I look for specific type-of somewhere in Cells, where I am 
> doing MOPpish stuff. But at the abstraction level that is the MOP, the 
> equivalent question is "where do me need an exact match on metaclass?"

When you define your own metaclass you also have to define a method on 
validate-superclass. Consider the following metaclass:

(defclass my-metaclass (standard-class)
   ())

A straightforward thing to do would be this:

(defmethod validate-superclass
            ((class my-metaclass)
             (superclass standard-class))
   t)

However, this is too general: The purpose of validate-superclass is to 
ensure that only classes of compatible metaclasses can inherit from each 
other. However, this definition states that my-metaclass and any 
subclass thereof is compatible with standard-class and any subclass 
thereof. You cannot possibly know that, especially in the cass of the 
second argument, which actually defeats the purpose of 
validate-superclass. The correct definition would be this:

(defmethod validate-superclass
   ((class (eq-class my-metaclass))
    (superclass (eq-class standard-class)))
   t)

(defmethod validate-superclass
   ((class (eq-class my-metaclass))
    (superclass (eq-class my-metaclass))
   t)

This is not exactly the best example for something like an eq-class 
specializer, because I would agree that the validation protocol is 
somewhat fishy, and actually think it would have been better to drop it 
completely and just leave the consequences "unspecified" of using 
incompatible metaclasses together, but there you go.


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/
From: Jack Unrue
Subject: Re: Better class type compare than typep?
Date: 
Message-ID: <3j7ue2t6a1n9h5khoc6sqcmthpmf8p48lq@4ax.com>
On Fri, 25 Aug 2006 09:05:46 +0200, Pascal Costanza <··@p-cos.net> wrote:
>
> Jack Unrue wrote:
> > On Fri, 25 Aug 2006 03:26:23 GMT, Jack Unrue <·······@example.tld> wrote:
> > 
> >> On 24 Aug 2006 12:01:08 -0700, "jmckitrick" <···········@yahoo.com> wrote:
> >>> I have an object that should be handled one way *IFF* it is truly a
> >>> direct instance of a certain class, not a derivative of said class.
> >> The following question is absolutely not meant to second-guess
> >> your design, even if it seems to. I'm just really curious. What is
> >> it about implementing a defmethod with an argument specializing on
> >> db::<rlg-record> that doesn't fit your needs?
> > 
> > Before anybody jumps in and points out that OP didn't want
> > such code to execute for subclasses, let me just say that there
> > are plenty of ways for that to happen, and avoiding defmethod
> > is not a solution. Right?
> 
> One of the earlier stages of the CLOS design had a way to "cancel" a 
> slot in a subclass so that it's not there in instance even if it would 
> otherwise be inherited from a superclass.
>
> While Kiczales et al. worked on the CLOS MOP specification, they were 
> experimenting with new specializers (similar to the already existing eql 
> specializers). One of them was eq-class which would have done what the 
> OP was asking for:
> 
> (defmethod foo ((obj (eq-class my-class)))
>    ; only applies when obj is a direct instance of my-class
>    )

Interesting, I didn't know about either of those experiments.

> There are actually cases where such a specializer would be useful, and 
> it would help a CLOS implementation to generate more efficient code for 
> such cases.
> 
> Eiffel actually has a feature to "cancel" methods in subclasses.
> 
> So what the OP asked for is something that others have thought of 
> before. Apparently, there are people who think these things could be useful.

I accept that.

> Do you think that eql specializers are useful? Well, they complicate a 
> CLOS implementation considerably, and Kiczales has argued for dropping 
> them in the end. Indeed, TinyCLOS doesn't have them anymore.

I think eql specializers are useful and I have a particular use-case
where I find them valuable -- but the use case I favor here is not
object-oriented, rather it's just taking advantage of CLOS method
dispatch as a substitute for length CASE/ECASE forms which has the
additional nice propery of extensibility (method combinations and such).

I tried to make clear that I was not passing judgement; as you have
illustrated, I'm not omniscient and I wrote in the part you snipped
that I was curious as to the OP's motivations.

My personal view is that trying to *constrain* code to run only for
a *specific* class is pointless and a sign of poor OO design. It's
pointless because unless one is willing to wrap the majority of CL
in a wrapper that enforces policy like this, and somehow disable
existing features, you can't stop someone from getting around the
type check that the OP mentioned wanting to do.

While recognizing your superior knowledge wrt to the MOP and
CLOS, I would hope that you could understand how someone might
consider this to be bad OO design, even if you don't personally
agree. I think it's bad because the end result is tight coupling
when the goal should be loose coupling. Whereas you can use existing
CLOS features to get the right code to run for such an object, in a
way that is extendable.

But again, I have to stress that I didn't know the OP's motivations.

> Just because CLOS has a feature doesn't mean that it is the obvious 
> right thing to add it to an object system. Just because CLOS doesn't 
> have a feature doesn't mean that it is the obvious wrong thing to add it 
> to an object system.

If features like you mentioned were added to CLOS, I would spend time
carefully evaluating the circumstances in which I might be inclined
to use them.

> Object systems don't grow on trees.

I must have chosen a really bad way to phrase what I wrote, because
I did not mean to imply anything of the sort.

-- 
Jack Unrue
From: Pascal Costanza
Subject: Re: Better class type compare than typep?
Date: 
Message-ID: <4l9402Fqqr2U2@individual.net>
Jack Unrue wrote:

> I think eql specializers are useful and I have a particular use-case
> where I find them valuable -- but the use case I favor here is not
> object-oriented, rather it's just taking advantage of CLOS method
> dispatch as a substitute for length CASE/ECASE forms which has the
> additional nice propery of extensibility (method combinations and such).

I think that's ok.

> My personal view is that trying to *constrain* code to run only for
> a *specific* class is pointless and a sign of poor OO design.

Common Lisp is very obviously not about being pure. Just look at the 
spec. ;-)

>> Object systems don't grow on trees.
> 
> I must have chosen a really bad way to phrase what I wrote, because
> I did not mean to imply anything of the sort.

I didn't mean to attack you. If I have given that impression, I have to 
apologize.


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/
From: Jack Unrue
Subject: Re: Better class type compare than typep?
Date: 
Message-ID: <acnue29qau9ge5ka9bku203sf8s7p5mvun@4ax.com>
On Fri, 25 Aug 2006 22:13:54 +0200, Pascal Costanza <··@p-cos.net> wrote:
> I wrote:
> 
> > My personal view is that trying to *constrain* code to run only for
> > a *specific* class is pointless and a sign of poor OO design.
> 
> Common Lisp is very obviously not about being pure. Just look at the 
> spec. ;-)

But but but... /me says in mock indignation :-)

> >> Object systems don't grow on trees.
> > 
> > I must have chosen a really bad way to phrase what I wrote, because
> > I did not mean to imply anything of the sort.
> 
> I didn't mean to attack you. If I have given that impression, I have to 
> apologize.

No apology necessary, Pascal.

This exchange with you, and your other post that mentioned the
meta-class validation protocol, did prompt me to finally get with
the program and order a copy of AMOP!

-- 
Jack Unrue