So, I recently discovered (some months too late) that I've made one of
the classic blunders of OO design in a code I'm working on.
Specifically, I used inheritance to model containment. This was my
first attempt at writing an OO program that does anything non-trivial,
some I'm willing to chalk it up to a learning experience.
One of the reasons I did this is that it seemed to flow naturally from
multiple inheritance and the non-standard method combinations. If I
wanted to do one thing after another with the things that the object
"contained" via inheritance, there was the PROGN method combination. I
could sum things with +, and so on and so forth. But just 'cause you
can do something doesn't mean you should, and now I've got to make a
decision between rewriting something or living with it becoming more
and more annoying to work around.
However, after I came to this realization, I started thinking of other
uses for non-standard method combinations, and there really wasn't
anything compelling that sprang to mind. I'm probably just not
thinking of something, and I'd love to know what.
TIA,
Pillsy
Pillsy wrote:
> So, I recently discovered (some months too late) that I've made one of
> the classic blunders of OO design in a code I'm working on.
> Specifically, I used inheritance to model containment. This was my
> first attempt at writing an OO program that does anything non-trivial,
> some I'm willing to chalk it up to a learning experience.
>
> One of the reasons I did this is that it seemed to flow naturally from
> multiple inheritance and the non-standard method combinations. If I
> wanted to do one thing after another with the things that the object
> "contained" via inheritance, there was the PROGN method combination. I
> could sum things with +, and so on and so forth. But just 'cause you
> can do something doesn't mean you should, and now I've got to make a
> decision between rewriting something or living with it becoming more
> and more annoying to work around.
>
> However, after I came to this realization, I started thinking of other
> uses for non-standard method combinations, and there really wasn't
> anything compelling that sprang to mind. I'm probably just not
> thinking of something, and I'd love to know what.
>
> TIA,
> Pillsy
>
>
Consider writing a persistent object method; its job is to collect
information sufficient to reconstruct a set of objects in a different
process. Each of the components knows something about how to save and
restore the portions of the objects that it implements. One way to do
this is to use a progn combination method to form the "save structure".
-- Jeff Barnett
From: Rainer Joswig
Subject: Re: Non-standard method combinations: what good are they?
Date:
Message-ID: <2007070400442116807-joswig@lispde>
On 2007-07-04 00:12:53 +0200, Pillsy <·········@gmail.com> said:
> So, I recently discovered (some months too late) that I've made one of
> the classic blunders of OO design in a code I'm working on.
> Specifically, I used inheritance to model containment. This was my
> first attempt at writing an OO program that does anything non-trivial,
> some I'm willing to chalk it up to a learning experience.
>
> One of the reasons I did this is that it seemed to flow naturally from
> multiple inheritance and the non-standard method combinations. If I
> wanted to do one thing after another with the things that the object
> "contained" via inheritance, there was the PROGN method combination. I
> could sum things with +, and so on and so forth. But just 'cause you
> can do something doesn't mean you should, and now I've got to make a
> decision between rewriting something or living with it becoming more
> and more annoying to work around.
>
> However, after I came to this realization, I started thinking of other
> uses for non-standard method combinations, and there really wasn't
> anything compelling that sprang to mind. I'm probably just not
> thinking of something, and I'd love to know what.
>
> TIA,
> Pillsy
For a useful example see here:
'Design by Contract' via Method Combination:
http://www.muc.de/~hoelzl/tools/dbc/dbc-intro.html
http://www.muc.de/~hoelzl/tools/dbc/dbc.lisp
http://www.muc.de/~hoelzl/tools/dbc/dbc-test.lisp
Another example:
I once wrote a kind of report generator. The report
had captions, title, cells, rows, ... I was using a method combination
like a template to assemble all the necessary parts
of the tables. This meant writing a
(defmethod show-table :title ...)
(defmethod show-table :caption ...)
(defmethod show-table :cell ...)
The special method combination then was assembling the methods and
determining the layout. The basic idea behind that: a) the individual methods
are much more declarative. b) the method combination allows extremely
flexible reuse in one place.
--
http://lispm.dyndns.org/
Pillsy <·········@gmail.com> wrote:
> However, after I came to this realization, I started thinking of other
> uses for non-standard method combinations, and there really wasn't
> anything compelling that sprang to mind. I'm probably just not
> thinking of something, and I'd love to know what.
Here's one I like:
(defgeneric point= (a b)
(:method-combination and))
(defclass point ()
((x :initarg :x :reader point-x)
(y :initarg :y :reader point-y)))
(defun make-point (x y)
(make-instance 'point :x x :y y))
(defmethod point= and ((a point) (b point))
(and (= (point-x a) (point-x b))
(= (point-y a) (point-y b))))
(defclass color-point (point)
((color :initarg :color :reader point-color)))
(defun make-color-point (x y c)
(make-instance 'color-point :x x :y y :color c))
(defmethod point= and ((a color-point) (b color-point))
(string= (point-color a) (point-color b)))
--
MySpace: http://www.myspace.com/didierverna
Didier Verna, ······@lrde.epita.fr, http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 44 08 01 85
94276 Le Kremlin-Bic�tre, France Fax.+33 (1) 53 14 59 22 ······@xemacs.org
Didier Verna wrote:
>> other uses for non-standard method combinations, ..
>
> Here's one I like:
>
> (defmethod point= and ((a color-point) (b color-point))
> (string= (point-color a) (point-color b)))
Sweet!, but:
(point= (make-color-point 10 10 "red") (make-point 10 10))
=>T
which I'm not sure I like... so
(defmethod point= and ((a color-point) (b point)) nil)
but now:
(point= (make-color-point 1 1 "red")
(make-color-point 1 1 "red"))
=>nil
Which is faintly vexing. Am I now back to doing it the old way?
Cheers,
John.
--
Contractor in Cambridge UK -- http://www.aspden.com
John Lawrence Aspden <····@aspden.com> wrote:
> (point= (make-color-point 10 10 "red") (make-point 10 10))
> =>T
>
> which I'm not sure I like... so
>
> (defmethod point= and ((a color-point) (b point)) nil)
>
> but now:
>
> (point= (make-color-point 1 1 "red")
> (make-color-point 1 1 "red"))
> =>nil
>
> Which is faintly vexing. Am I now back to doing it the old way?
No. You're now ready for a bit of MOP programming :-)
--
MySpace: http://www.myspace.com/didierverna
Didier Verna, ······@lrde.epita.fr, http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 44 08 01 85
94276 Le Kremlin-Bic�tre, France Fax.+33 (1) 53 14 59 22 ······@xemacs.org
John Lawrence Aspden <····@aspden.com> wrote:
> (point= (make-color-point 10 10 "red") (make-point 10 10))
> =>T
>
> which I'm not sure I like... so
>
> (defmethod point= and ((a color-point) (b point)) nil)
>
> but now:
>
> (point= (make-color-point 1 1 "red")
> (make-color-point 1 1 "red"))
> =>nil
>
> Which is faintly vexing. Am I now back to doing it the old way?
No. You're now ready for a bit of MOP programming :-)
--
MySpace: http://www.myspace.com/didierverna
Didier Verna, ······@lrde.epita.fr, http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 44 08 01 85
94276 Le Kremlin-Bic�tre, France Fax.+33 (1) 53 14 59 22 ······@xemacs.org