This question might be paraphrased 'How to call GF?'. But I'd rather
ask 'How to choose GF.' I have several classes: ORDER, SERVICE,
SERVICE-RECORD. All of them have that call be called
'insert-date'. For the first time I've called appropriated accessors
ORDER-INSERT-DATE, SERVICE-INSERT-DATE etc. It seems very common to
those coming from C++ (as me). But being used such names for a while
I've asked myself 'Won't it be more convenient to call GF INSERT-DATE
and define appropriate methods on it (specializing it in proper
way). E.g.
(defgeneric insert-date (object)
(:method ((self order)) ....
(:method ((self sevice)) ....
(:method ((self service-record)) ...
....
)
I'm sure this approach (if it can be called 'approach' at all) should
be known. What is its benefits and drawbacks ?
--
Vladimir Zolotykh ······@eurocom.od.ua
Conceivably this insert-date is just one bit of behavior these different
classes will share. You might want to have a common /class/ such as
Document and put stuff in there.
then you could have
(defmethod insert-date ((self Document) a-date) ...
and:
(defmethod insert-date :after (or :before or :around) ((self Order)
a-date)
<special processing>)
btw, if it so happens DATE is just a slot, you can:
(defmethod (setf date) :after (new-date (self Order))...)
Vladimir Zolotykh wrote:
> I've asked myself 'Won't it be more convenient to call GF INSERT-DATE
> and define appropriate methods on it (specializing it in proper
> way). E.g.
>
> (defgeneric insert-date (object)
> (:method ((self order)) ....
> (:method ((self sevice)) ....
> (:method ((self service-record)) ...
> ....
> )
>
> I'm sure this approach (if it can be called 'approach' at all) should
> be known. What is its benefits and drawbacks ?
that approach is fine, tho again look for aspects of the date handling
which are in common and can be placed in a primary unspecialized method.
i cannot think of any drawbacks.
kenny
clinisys
Vladimir Zolotykh <······@eurocom.od.ua> writes:
> I have several classes: ORDER, SERVICE, SERVICE-RECORD. All of them
> have that call be called 'insert-date'. For the first time I've
> called appropriated accessors ORDER-INSERT-DATE, SERVICE-INSERT-DATE
> etc.
If the action performed by the INSERT-DATE is well defined and
semantically the same for all your classes, then the GF is the right
way to go, i.e., GFs establish a kind of protocol -- the classes that
obey that protocol define methods for that GF. This can be more
obvious if all the classes have a common superclass and the GF is
defined for that superclass. In your case it could be a class with a
slot named DATE and INSERT-DATE GF is meant to fill that slot, but the
way it is done may be different for subclasses (if it would not be
different, then there would be no need for different methods, and
possibly no need for GF either).
> It seems very common to those coming from C++ (as me).
I thought in C++ one should have only one function (heavily
overloaded) which does different things depending on what number of
arguments it gets passed :)
> But being used such names for a while I've asked myself 'Won't it be
> more convenient to call GF INSERT-DATE and define appropriate
> methods on it (specializing it in proper way). E.g.
>
> (defgeneric insert-date (object)
> (:method ((self order)) ....
> (:method ((self sevice)) ....
> (:method ((self service-record)) ...
> ....
> )
You might have discovered the right thing or the wrong thing depending
on what those methods do.
> I'm sure this approach (if it can be called 'approach' at all) should
> be known. What is its benefits and drawbacks ?
The obvious (to me) benefit of generic functions is, as I have
described above, that if they have well defined semantics, the system
becomes easily extensible -- if you later add some other kind of
document you just define the relevant methods for it and the new class
seamlessly integrates into your application (possibly running).
I guess you would greatly benefit from reading Sonya E. Keene's
"Object-Oriented Programming in Common Lisp: A Programmer's Guide to
CLOS".
--
Janis Dzerins
Eat shit -- billions of flies can't be wrong.
Janis Dzerins <·····@latnet.lv> writes:
> Vladimir Zolotykh <······@eurocom.od.ua> writes:
>
> > I have several classes: ORDER, SERVICE, SERVICE-RECORD. All of them
> > have that call be called 'insert-date'. For the first time I've
> > called appropriated accessors ORDER-INSERT-DATE, SERVICE-INSERT-DATE
> > etc.
>
> If the action performed by the INSERT-DATE is well defined and
> semantically the same for all your classes, then the GF is the right
> way to go, i.e., GFs establish a kind of protocol -- the classes that
> obey that protocol define methods for that GF.
Er, almost. A GF is a protocol. *Methods* defined on that GF extend
that protocol to be defined in terms of the classes those methods
specialize on. For a C++ head, this is an important point. Objects
are objects, they're instances of classes, which define the type and
the slots, but no methods. Generic functions are the idea of a
function, and methods define this idea for certain types. Someone on
this newsgroup called CL a GF-oriented language, and I think that's a
good description.
When I write a GF, I always write a defgeneric form, where I explain
the function to myself and later readers of the code. Then, when I
encounter more classes that I wish were supported by the GF, I add
methods to the GF for them. Occasionally I find myself wanting to
have two GF's with the same name. It's at times like these that I'm
glad I impose self-discipline this way, because what I've found is two
different concepts that both have a good claim to a single name. If I
thought of methods as belonging to classes, I'd have made a mess of
the GF by confusing two concepts.
It's reasonable for methods to belong to classes in languages with a
(tell object message arg1 arg2 ...) syntax [or obj->message(...), or
(obj message: arg1 and: arg2 ...), if you swing like that]. But in a
language like CL where a method is just a part of a larger GF that
looks like a normal function, it's confusing to think of things that
way.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
In article <···············@eurocom.od.ua>,
Vladimir Zolotykh <······@eurocom.od.ua> wrote:
>This question might be paraphrased 'How to call GF?'. But I'd rather
>ask 'How to choose GF.' I have several classes: ORDER, SERVICE,
>SERVICE-RECORD. All of them have that call be called
>'insert-date'. For the first time I've called appropriated accessors
>ORDER-INSERT-DATE, SERVICE-INSERT-DATE etc. It seems very common to
>those coming from C++ (as me). But being used such names for a while
>I've asked myself 'Won't it be more convenient to call GF INSERT-DATE
>and define appropriate methods on it (specializing it in proper
>way). E.g.
>
> (defgeneric insert-date (object)
> (:method ((self order)) ....
> (:method ((self sevice)) ....
> (:method ((self service-record)) ...
> ....
> )
>
>I'm sure this approach (if it can be called 'approach' at all) should
>be known. What is its benefits and drawbacks ?
This is appropriate if some parts of your program may be handed an object
that could be in any of these classes, and it needs to insert the date
without caring which class it is.
If these classes don't really have anything in common, then you get better
error checking by using different generic functions for each. If an ORDER
accidentally gets passed to a routine that expects a SERVICE, you'll get an
error when it tries to call SERVICE-INSERT-DATE.
If you want them to be interchangeable as far as inserting dates goes, you
might want to use a mixin so you don't have to write multiple methods:
(defclass has-date ...)
(defclass order (has-date ...) ...)
(defclass service (has-date ...) ...)
(defmethod insert-date ((self has-date)) ...)
--
Barry Margolin, ······@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Barry Margolin wrote:
>
> If you want them to be interchangeable as far as inserting dates goes, you
> might want to use a mixin so you don't have to write multiple methods:
>
> (defclass has-date ...)
> (defclass order (has-date ...) ...)
> (defclass service (has-date ...) ...)
As I could decide this seems me more reliable and convenient. But this
requires more deeper understanding of the problem and relations
between classes and their interfaces. But I think it worth spending
time.
--
Vladimir Zolotykh ······@eurocom.od.ua
Barry Margolin <······@genuity.net> writes:
> In article <···············@eurocom.od.ua>,
> Vladimir Zolotykh <······@eurocom.od.ua> wrote:
>>This question might be paraphrased 'How to call GF?'. But I'd rather
>>ask 'How to choose GF.' I have several classes: ORDER, SERVICE,
>>SERVICE-RECORD. All of them have that call be called
>>'insert-date'. For the first time I've called appropriated accessors
>>ORDER-INSERT-DATE, SERVICE-INSERT-DATE etc. It seems very common to
>>those coming from C++ (as me). But being used such names for a while
>>I've asked myself 'Won't it be more convenient to call GF INSERT-DATE
>>and define appropriate methods on it (specializing it in proper
>>way). E.g.
>>
>> (defgeneric insert-date (object)
>> (:method ((self order)) ....
>> (:method ((self sevice)) ....
>> (:method ((self service-record)) ...
>> ....
>> )
>>
>>I'm sure this approach (if it can be called 'approach' at all) should
>>be known. What is its benefits and drawbacks ?
>
> This is appropriate if some parts of your program may be handed an object
> that could be in any of these classes, and it needs to insert the date
> without caring which class it is.
>
> If these classes don't really have anything in common, then you get better
> error checking by using different generic functions for each. If an ORDER
> accidentally gets passed to a routine that expects a SERVICE, you'll get an
> error when it tries to call SERVICE-INSERT-DATE.
>
> If you want them to be interchangeable as far as inserting dates goes, you
> might want to use a mixin so you don't have to write multiple methods:
>
What is a mixin? (I think I know the basics of them, but I never got
to use Flavors :(, so I think my definition is somewhat incorrect)
> (defclass has-date ...)
> (defclass order (has-date ...) ...)
> (defclass service (has-date ...) ...)
>
> (defmethod insert-date ((self has-date)) ...)
>
> --
> Barry Margolin, ······@genuity.net
> Genuity, Woburn, MA
> *** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
> Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
--
BPT <···@tunes.org> /"\ ASCII Ribbon Campaign
backronym for Linux: \ / No HTML or RTF in mail
Linux Is Not Unix X No MS-Word in mail
Meme plague ;) ---------> / \ Respect Open Standards
>>>>> On Wed, 16 Jan 2002 00:49:34 GMT, Brian P Templeton ("Brian") writes:
Brian> Barry Margolin <······@genuity.net> writes:
>> If you want them to be interchangeable as far as inserting dates goes, you
>> might want to use a mixin so you don't have to write multiple methods:
Brian> What is a mixin? (I think I know the basics of them, but I never got
Brian> to use Flavors :(, so I think my definition is somewhat incorrect)
A "mixin" is simply a class that does not stand on its own and is
intended to be combined with a "primary" class. For example, if
you wish to compose an ice cream that contains nuts and candy chunks:
SWEET-CREAM might be the primary class, and NUTS-MIXIN and CANDY-MIXIN
would be the mixin classes. If you want an ice cream concoction,
you can't get it by instantiating only the nuts or the candies.