From: ·············@my-deja.com
Subject: mixim classes
Date: 
Message-ID: <93epa4$d2e$1@nnrp1.deja.com>
Could someone please explain what mixim classes are? I know it's
something related to clos or flavors, but that's all... O:-)

TIA


Sent via Deja.com
http://www.deja.com/

From: Sunil Mishra
Subject: Re: mixim classes
Date: 
Message-ID: <3A5B6EED.4080300@everest.com>
·············@my-deja.com wrote:

> Could someone please explain what mixim classes are? I know it's
> something related to clos or flavors, but that's all... O:-)
> 
> TIA
> 
> 
> Sent via Deja.com
> http://www.deja.com/

That's mixin classes :-)

The best I can do is offer a simple example... That is what I had 
started with, and with experience learned to generalize the idea. A 
mixin class, in brief, is something that is capable of adding through 
inheritence an arbitrary set of capabilities to a given class. A common 
use of mixin classes is for providing property lists in classes. You can 
define a mixin as follows:

(defclass property-list-mixin ()
   ((properties :initform nil :accessor properties)))

Then you can define methods on this mixin class:

(defmethod get-property ((object property-list-mixin) key)
   (getf (properties object) key))

(defmethod (setf get-property) (value (object property-list-mixin) key)
   ...)

Mixins are generally used for modifying the behavior of classes. In the 
example the behavior is new, provided through new generic functions that 
did not exist in the original class. Sometimes they add on some behavior 
to an existing generic function on a class. This is generally done 
through the addition of a before/after/around method.

The best way to find out more would be to:

1. Try to get a hold of Sonya Keene's CLOS book (I don't have the full 
title on me).

2. Read some code. That might of course prove difficult, as most 
software that will find good use for mixin classes will turn out to be 
rather large and complex.

Sunil
From: Xenophon Fenderson the Carbon(d)ated
Subject: Re: mixim classes
Date: 
Message-ID: <w4oelycqhpl.fsf@eco-wks5.cinci.irtnog.org>
>>>>> "Sunil" == Sunil Mishra <············@everest.com> writes:

    Sunil> 1. Try to get a hold of Sonya Keene's CLOS book (I don't
    Sunil> have the full title on me).

@Book{keene89:oopcl,
  author =	 {Sonya E. Keene},
  title = 	 {Object-Oriented Programming in COMMON LISP: A
                  Programmer's Guide to CLOS},
  publisher = 	 {Addison-Wesley Publishing Company},
  year = 	 1989,
  address =	 {Reading, Massachusetts},
  note =	 {COMMON LISP (Computer program language);
                  Object-oriented programming (Computer science)},
  annote =	 {QA76.73.C28K44 1988}
}

-- 
"Die, spork user! And burn in fiery torment!" -- Handy, the Handpuppet of Doom
From: ·············@my-deja.com
Subject: Re: mixim classes
Date: 
Message-ID: <93hen6$eu9$1@nnrp1.deja.com>
In article <················@everest.com>,
  Sunil Mishra <············@everest.com> wrote:
> ·············@my-deja.com wrote:
>
> The best way to find out more would be to:
>
> 1. Try to get a hold of Sonya Keene's CLOS book (I don't have the
full
> title on me).

I'll see if I can get myself a copy. It's a pity that most good books
on CL seem to be out of print or at least difficult to find.. :-P

> 2. Read some code. That might of course prove difficult, as most
> software that will find good use for mixin classes will turn out to

Any recomendation? O:-)


Sent via Deja.com
http://www.deja.com/
From: Pierre R. Mai
Subject: Re: mixim classes
Date: 
Message-ID: <87lmse2ift.fsf@orion.bln.pmsf.de>
·············@my-deja.com writes:

> In article <················@everest.com>,
>   Sunil Mishra <············@everest.com> wrote:
> > ·············@my-deja.com wrote:
> >
> > The best way to find out more would be to:
> >
> > 1. Try to get a hold of Sonya Keene's CLOS book (I don't have the
> full
> > title on me).
> 
> I'll see if I can get myself a copy. It's a pity that most good books
> on CL seem to be out of print or at least difficult to find.. :-P

The last time I looked, the book by Keene was an exception to this
rule, and was still readily available through the publisher (published
by Symbolics Press in cooperation with Addison-Wesley, where it was
still available), and hence through all reputable booksellers,
including online retailers like amazon.com, etc.

> > 2. Read some code. That might of course prove difficult, as most
> > software that will find good use for mixin classes will turn out to
> 
> Any recomendation? O:-)

Most major systems implemented in CL using CLOS will probably exhibit
mixin-classes somewhere...

Regs, Pierre.

-- 
Pierre R. Mai <····@acm.org>                    http://www.pmsf.de/pmai/
 The most likely way for the world to be destroyed, most experts agree,
 is by accident. That's where we come in; we're computer professionals.
 We cause accidents.                           -- Nathaniel Borenstein
From: Pierre R. Mai
Subject: Re: mixim classes
Date: 
Message-ID: <87itni2h3i.fsf@orion.bln.pmsf.de>
"Pierre R. Mai" <····@acm.org> writes:

> > I'll see if I can get myself a copy. It's a pity that most good books
> > on CL seem to be out of print or at least difficult to find.. :-P
> 
> The last time I looked, the book by Keene was an exception to this
> rule, and was still readily available through the publisher (published
> by Symbolics Press in cooperation with Addison-Wesley, where it was
> still available), and hence through all reputable booksellers,
> including online retailers like amazon.com, etc.

Oops, just looked at Amazon, and it seems the books status seems to
have changed.  OTOH Amazon informs one that at least one of its
merchant partners seems to offer a used copy of the book...

Sorry for not confirming this earlier...

Regs, Pierre.

-- 
Pierre R. Mai <····@acm.org>                    http://www.pmsf.de/pmai/
 The most likely way for the world to be destroyed, most experts agree,
 is by accident. That's where we come in; we're computer professionals.
 We cause accidents.                           -- Nathaniel Borenstein
From: ·············@my-deja.com
Subject: Re: mixim classes
Date: 
Message-ID: <93hesj$f0c$1@nnrp1.deja.com>
In article <················@naggum.net>,
  Erik Naggum <····@naggum.net> wrote:
> * ·············@my-deja.com
> | Could someone please explain what mixim classes are? I know it's
> | something related to clos or flavors, but that's all... O:-)
>
>   It's probably a misspelling of "mixin classes", as in "mix in".

Yes O:-)

>   Mixins are used for a lot of different things, and there is
probably as
>   many ways to describe the concept as there are usages, some of which
>   won't even look like they're describing the same thing.  Did you
have any
>   particular usage in mind?

No, I was just curious, thanks.  :-) Do you know of any sample code
that uses this technique that I can check out?

TIA


Sent via Deja.com
http://www.deja.com/
From: Will Deakin
Subject: Re: mixim classes
Date: 
Message-ID: <3A5C6BE6.3050504@pindar.com>
·············@my-deja.com wrote:


> No, I was just curious, thanks.  :-) Do you know of any sample code
> that uses this technique that I can check out?
IIRC there is some stuff in PAIP by Norvig about mixin's...

:)will
From: Pierre R. Mai
Subject: Examples of Mix-in classes (was Re: mixim classes)
Date: 
Message-ID: <87ofxa2imc.fsf_-_@orion.bln.pmsf.de>
·············@my-deja.com writes:

> No, I was just curious, thanks.  :-) Do you know of any sample code
> that uses this technique that I can check out?

Here's a small snippet from our in-house HTTP-server library, dealing
with the validation of HTTP-requests.  In the following we have the
class RESOURCE, which represents things that can be accessed via HTTP
requests, resulting in responses, possibly containing entities (note
that this is conceptually close to the HTTP standards).  The main
request-handling happens through the access-resource and
access-resource-using-method generic functions (abridged code ahead):

(defclass resource ()
  ())

(defgeneric resource-allowed-methods (resource))

(defgeneric access-resource (resource request)
  (:argument-precedence-order request resource))

(defgeneric access-resource-using-method (resource request method)
  (:argument-precedence-order method request resource))

(defmethod access-resource ((resource resource) request)
  (let ((method (request-method request))
        (allowed-methods (resource-allowed-methods resource)))
    (if (member method allowed-methods)
        (access-resource-using-method resource request method)
        (error 'clash-error :code +HTTP-Code-Method-Not-Allowed+
               :entity-initargs (list :allow allowed-methods)))))

To outboard validation of requests from the real request-handling done
by the resource (e.g. to dynamically generate a response), we have the
following code:

;;; This is the error raised if validation doesn't succeed:

(define-condition clash-validation-error (clash-error)
  ()
  (:default-initargs :code +HTTP-Code-Unauthorized+))

;;; The mix-in class itself:

(defclass validation-mixin ()
  ((validators :initarg :validators :initform nil
               :accessor validation-mixin-validators)))

;;; The added behaviour: We validate the request using all validators,
;;; and collect the validation data into a list.  We then establish a
;;; dynamic environment where the validation data is available through
;;; the with-validation-data macro, and proceed with normal
;;; processing.  If validation fails, one of the validators will raise
;;; a clash-validation-error...

(defvar *validation-data* nil)

(defmethod access-resource :around ((resource validation-mixin) request)
  (do* ((data nil (nconc data (validate-access validator request)))
        (validators (validation-mixin-validators resource) (cdr validators))
        (validator (car validators) (car validators)))
       ((null validators)
        (let ((*validation-data* data))
          (call-next-method)))))

Regs, Pierre.


-- 
Pierre R. Mai <····@acm.org>                    http://www.pmsf.de/pmai/
 The most likely way for the world to be destroyed, most experts agree,
 is by accident. That's where we come in; we're computer professionals.
 We cause accidents.                           -- Nathaniel Borenstein