Hi Lispers
if i understand it correctly, most oo-design is based on inheritance
relationships based on a IS-A relations, e.g.:
toyota IS-A car IS-A vehicle
Is there also a lisp way of doing something like:
bike IS-MADE-OF wheel IS-MADE-OF spokes
frame IS-MADE-OF tube
chain IS-MADE-OF steel
This would allow a kind of construction of objects from basic "parts",
instead of the classification type of relation used in the IS-A
approach. Are there any lisp libraries implementing something like
this or are there literature references?
thanks,
Marc
--
------------------------------------------------------------------------------
email: marc dot hoffmann at users dot whh dot wau dot nl
------------------------------------------------------------------------------
······@No-Such-Domain.anywhere (see.signature) writes:
> if i understand it correctly, most oo-design is based on inheritance
> relationships based on a IS-A relations, e.g.:
>
> toyota IS-A car IS-A vehicle
>
(defclass vehicle ()
())
(defclass car (vehicle)
((wheel-count :initform 4
:allocation :class
:reader wheel-count)))
(defclass toyota (car)
(next-service-interval))
> Is there also a lisp way of doing something like:
>
> bike IS-MADE-OF wheel IS-MADE-OF spokes
> frame IS-MADE-OF tube
> chain IS-MADE-OF steel
(defclass bike (vehicle)
(wheels
frame
chain))
(defclass vehicle-part ()
())
(defclass wheel (vehicle-part)
(spokes))
etc...
... Or am I being dense, and you look for another thing? The
is-made-of relationship can be modelled by slots containing an object
that "makes" the containing object just fine.
Rudi
In article <····················@Flex111.dNWL.WAU.NL>,
see.signature wrote:
> Is there also a lisp way of doing something like:
>
> bike IS-MADE-OF wheel IS-MADE-OF spokes
> frame IS-MADE-OF tube
> chain IS-MADE-OF steel
>
> This would allow a kind of construction of objects from basic "parts",
> instead of the classification type of relation used in the IS-A
> approach. Are there any lisp libraries implementing something like
> this or are there literature references?
You ask about Lisp, but this is a general concept called delegation.
For general info on OO concepts the OO faq is pretty comprehensive:
ftp://rtfm.mit.edu/pub/usenet/news.answers/object-faq/
As someone else has pointed out, in Lisp you implement delegation by
having slots containing instances of other classes.
Andrew
Sent via Deja.com http://www.deja.com/
Before you buy.
On Mon, 03 Apr 2000 14:54:58 GMT, Andrew Cooke
<······@andrewcooke.free-online.co.uk> wrote:
>You ask about Lisp, but this is a general concept called delegation.
Can someone give a very brief summary of how delegation is
different from the "has a" relationship? The way I read the
original question, the author was not aware of any such
relationship as "has a" and was complaining about trying to
apply the "is a" relationship in place of it.
<······@sez.not> wrote in message
·······································@4ax.com...
> On Mon, 03 Apr 2000 14:54:58 GMT, Andrew Cooke
> <······@andrewcooke.free-online.co.uk> wrote:
>
> >You ask about Lisp, but this is a general concept called delegation.
>
> Can someone give a very brief summary of how delegation is
> different from the "has a" relationship? The way I read the
> original question, the author was not aware of any such
> relationship as "has a" and was complaining about trying to
> apply the "is a" relationship in place of it.
>
Many OO languages allow only a single superclass to a given subclass, but
you still want to inherit the interface of another class. Sometimes, you
may wish to subclass a class that is unsubclassable (e.g., "sealed" classes
in Dylan). In these cases, you often have no choice but to either (1)
reimplement the entire behavior of the superclass in the subclass or (2)
create an instance of the desired (but unachievable) superclass and forward
messages from the subclass to the created instance to achieve the behavior
of the wanted superclass. Even though option two is less work than one,
drawbacks remain.
One drawback of this approach is that forwarding methods must be written and
maintained on the "subclass" object - a major pain. Another, more insidious
drawback is that most of the single-inheritance systems have a notion of an
object from whose class the given method is resolved. By sending a message
to a delagatee, the identity of the object which the original message is
sent to is lost, and a possibility of ambiguity in method lookup arises.
Self, a Smalltalk derivative, handled this problem by maintaining the
identity of the original "self" object in all message sends, only using the
equivalent of delegation during message lookup (message application was
always WRT the original object) [And actually, there were no "classes" per
se, as well. Each object was its own class]. They called this message
lookup system "delegation". The other languages bastardized the usage to
also include the poor copies of delegation that they provided. I prefer the
term "message forwarding" for the scaled down version.
All that being said, and to bring the conversation back to Common Lisp, it
is unclear if CLOS, allowing multiple superclasses and having an extensive
MOP, actually needs a "delagative" construct. It is clear that IS-PART-OF
relationships need to be separated from IS-A relationships, but the
differences between inheritance and slot inclusion are sufficient to reflect
the different usages. Nonetheless, if you feel a need to cobble up some
type of delagative construct, it would be relatively easy to do so.
faa
In article <·················@news.uswest.net>,
Frank A. Adrian <·······@uswest.net> wrote:
>All that being said, and to bring the conversation back to Common Lisp, it
>is unclear if CLOS, allowing multiple superclasses and having an extensive
>MOP, actually needs a "delagative" construct. It is clear that IS-PART-OF
>relationships need to be separated from IS-A relationships, but the
>differences between inheritance and slot inclusion are sufficient to reflect
>the different usages. Nonetheless, if you feel a need to cobble up some
>type of delagative construct, it would be relatively easy to do so.
Inheritance frequently can't be used to implement HAS-A or IS-PART-OF
delegation. The problem is that a car may have multiple wheels, each with
its own set of slots, but if WHEEL is a SUPERCLASS of CAR there will just
be one set of slots.
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, 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.
From: Fernando D. Mato Mira
Subject: Re: oo and made-of relationship in CL
Date:
Message-ID: <38EA195F.30305507@acm.org>
Barry Margolin wrote:
> In article <·················@news.uswest.net>,
> Frank A. Adrian <·······@uswest.net> wrote:
> >All that being said, and to bring the conversation back to Common Lisp, it
> >is unclear if CLOS, allowing multiple superclasses and having an extensive
> >MOP, actually needs a "delagative" construct. It is clear that IS-PART-OF
> >relationships need to be separated from IS-A relationships, but the
> >differences between inheritance and slot inclusion are sufficient to reflect
> >the different usages. Nonetheless, if you feel a need to cobble up some
> >type of delagative construct, it would be relatively easy to do so.
>
> Inheritance frequently can't be used to implement HAS-A or IS-PART-OF
> delegation. The problem is that a car may have multiple wheels, each with
> its own set of slots, but if WHEEL is a SUPERCLASS of CAR there will just
> be one set of slots.
In C++, you would have to create a class for each N-wheeled kind of vehicle,
inheriting N times _non-virtually_ from wheel (and indirectly, so you can
disabiguate
writing things like Wheel1::).
In Eiffel, you would also have to use repeated inheritance, and add the
appropriate renaming clauses.
In Lisp you would have to use the MOP.
Great for a Hennes-Mauritz "Bad Idea" ad.
--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
In article <·················@acm.org>,
"Fernando D. Mato Mira" <········@acm.org> wrote:
> Barry Margolin wrote:
> > In article <·················@news.uswest.net>,
> > Frank A. Adrian <·······@uswest.net> wrote:
> > >All that being said, and to bring the conversation back to Common
Lisp, it
> > >is unclear if CLOS, allowing multiple superclasses and having an
extensive
> > >MOP, actually needs a "delagative" construct. It is clear that
IS-PART-OF
> > >relationships need to be separated from IS-A relationships, but the
> > >differences between inheritance and slot inclusion are sufficient
to reflect
> > >the different usages. Nonetheless, if you feel a need to cobble up
some
> > >type of delagative construct, it would be relatively easy to do so.
> >
> > Inheritance frequently can't be used to implement HAS-A or
IS-PART-OF
> > delegation. The problem is that a car may have multiple wheels,
each with
> > its own set of slots, but if WHEEL is a SUPERCLASS of CAR there will
just
> > be one set of slots.
>
> In C++, you would have to create a class for each N-wheeled kind of
vehicle,
> inheriting N times _non-virtually_ from wheel (and indirectly, so you
can
> disabiguate
> writing things like Wheel1::).
[...]
OO languages do have arrays! You aren't forced to do everything via
inheritance. There's nothing to stop you creating an object for "n
wheeled vehicles" whose methods take indexes to appropriate wheels, for
example. (I'm sure you know this, but newbies do sometimes think that
everyting must be done with inheritance - in my experience, working with
Java for a living, inheritance is used much less than composition).
Andrew
Sent via Deja.com http://www.deja.com/
Before you buy.
Barry Margolin <······@bbnplanet.com> wrote in message
·····················@burlma1-snr2...
> In article <·················@news.uswest.net>,
> Inheritance frequently can't be used to implement HAS-A or IS-PART-OF
> delegation. The problem is that a car may have multiple wheels, each with
> its own set of slots, but if WHEEL is a SUPERCLASS of CAR there will just
> be one set of slots.
Actually, if I had an object that was held more than one subobject of a
given class (e.g., car has multiple wheels), I'd make a slot that held a
collection. I would probably not attempt to use inheritance to model
is-part-of relationships anyway. To me, inheritance generally means
"subclass has the attributes of superclass", not "subclass is implemented
like superclass" or "subclass contains superclass" (though I have been known
to cheat :-) .
Actually, I have always been somewhat dismayed that object languages don't
have explicit support for a notion of multiplicity for a given slot, usually
deferring to other language constructs to provide these capabilities. It
provides more flexibility in implementation, but at the cost of a less
direct mapping between logical model and code.
faa
> Can someone give a very brief summary of how delegation is
> different from the "has a" relationship?
IMHO, it's strictly an implementation matter: delegation is implementing an
'is-a' relationship using 'has-a' (for whatever reason). So if you call a
relationship 'delegation', the _intent_ is 'is-a', not 'has-a'.
Philip
--
Not getting what you want is sometimes a wonderful stroke of luck.
-----------------------------------------------------------------------------
Philip Lijnzaad, ········@ebi.ac.uk | European Bioinformatics Institute,rm A2-24
+44 (0)1223 49 4639 | Wellcome Trust Genome Campus, Hinxton
+44 (0)1223 49 4468 (fax) | Cambridgeshire CB10 1SD, GREAT BRITAIN
PGP fingerprint: E1 03 BF 80 94 61 B6 FC 50 3D 1F 64 40 75 FB 53
From: Friedrich Dominicus
Subject: Re: oo and made-of relationship in CL
Date:
Message-ID: <873dp22uur.fsf@inka.de>
>>>>> "AC" == Andrew Cooke <······@andrewcooke.free-online.co.uk> writes:
AC> In article <····················@Flex111.dNWL.WAU.NL>,
AC> see.signature wrote:
>> Is there also a lisp way of doing something like:
>>
>> bike IS-MADE-OF wheel IS-MADE-OF spokes
>> frame IS-MADE-OF tube
>> chain IS-MADE-OF steel
>>
>> This would allow a kind of construction of objects from basic "parts",
>> instead of the classification type of relation used in the IS-A
>> approach. Are there any lisp libraries implementing something like
>> this or are there literature references?
AC> You ask about Lisp, but this is a general concept called delegation.
AC> For general info on OO concepts the OO faq is pretty comprehensive:
AC> ftp://rtfm.mit.edu/pub/usenet/news.answers/object-faq/
What does this have to do with delegation? It's a relationship and can be
easily managed by having some sort of instance in each instance of another
class.
AC> As someone else has pointed out, in Lisp you implement delegation by
AC> having slots containing instances of other classes.
Yes, I just would not call it delegation
Regards
Friedrich
In article <··············@inka.de>,
Friedrich Dominicus <···················@inka.de> wrote:
> >>>>> "AC" == Andrew Cooke <······@andrewcooke.free-online.co.uk>
writes:
> AC> In article <····················@Flex111.dNWL.WAU.NL>,
> AC> see.signature wrote:
> >> Is there also a lisp way of doing something like:
> >>
> >> bike IS-MADE-OF wheel IS-MADE-OF spokes
> >> frame IS-MADE-OF tube
> >> chain IS-MADE-OF steel
> >>
> >> This would allow a kind of construction of objects from basic
"parts",
> >> instead of the classification type of relation used in the IS-A
> >> approach. Are there any lisp libraries implementing something like
> >> this or are there literature references?
>
> AC> You ask about Lisp, but this is a general concept called
delegation.
> AC> For general info on OO concepts the OO faq is pretty
comprehensive:
> AC> ftp://rtfm.mit.edu/pub/usenet/news.answers/object-faq/
> What does this have to do with delegation? It's a relationship and can
be
> easily managed by having some sort of instance in each instance of
another
> class.
>
> AC> As someone else has pointed out, in Lisp you implement delegation
by
> AC> having slots containing instances of other classes.
>
> Yes, I just would not call it delegation
Yes, I think I mis-read the original question, which was probably just
asking about "has-a" or "composition" relationships.
At the risk of muddying the water further, I would describe delegation
as "forwarding a request initially directed to one object to another
better able to handle it". In some languages this replaces inheritance
and is automated. In others the original object must forward the
request explicitly - this usually requires a "has-a" relationship, hence
the confusion (albeit maybe only in my head).
Andrew
Sent via Deja.com http://www.deja.com/
Before you buy.
Hi,
to clarify my earlier question about the IS-MADE-OF relationship:
If i have a bike which is made of hundreds of individual parts (spokes,
ball bearings, ...), that would mean that i need to put hundreds of
object instances in the slot of bike? And how about taking a wheel
away from the bike? Can i just dynamically delete a lot of slots from
a bike object?
I think i am looking for a system which allows to manage the complexity
of objects (e.g. a bike) which consist of a large number of parts
(slots). The main problem is related to dynamically changing all these
slots. Imagine starting to construct a bike: Your start with tubes,
make a frame, take some ball bearing, spokes and a rim, make a wheel,
add the wheel to the frame, start with the next wheel, .... .
yours,
Marc
--
------------------------------------------------------------------------------
email: marc dot hoffmann at users dot whh dot wau dot nl
------------------------------------------------------------------------------
see.signature <······@No-Such-Domain.anywhere> wrote in message
·························@Flex111.dNWL.WAU.NL...
| Hi,
|
| to clarify my earlier question about the IS-MADE-OF relationship:
|
| If i have a bike which is made of hundreds of individual parts (spokes,
| ball bearings, ...), that would mean that i need to put hundreds of
| object instances in the slot of bike?
If you want to model all these hundreds of parts, you will need hundreds of slots. But
you don't need to put them all into one class, bike. Your bike could be made of just
slots for, say frame, steering-mechanism, wheels, brake-system. Then wheels, for
example, could be a list of two wheel objects, each with slots of their own for spokes,
tube, tire.
| And how about taking a wheel
| away from the bike? Can i just dynamically delete a lot of slots from
| a bike object?
|
(defmethod remove-wheel ((my-bike bicycle-class) location)
"According to location (:front or :rear) delete one of the wheels in the wheels slot
and return it to caller"
(case location
(:front (let* ((wheels (get-wheels my-bike))
(old-wheel (car wheels)))
(setf (car wheels) nil)
old-wheel))
(:rear (let* ((wheels (get-wheels my-bike))
(old-wheel (cdr wheels)))
(setf (cdr wheels) nil)
old-wheel))
(otherwise nil)))
| I think i am looking for a system which allows to manage the complexity
| of objects (e.g. a bike) which consist of a large number of parts
| (slots). The main problem is related to dynamically changing all these
| slots
You don't need to do anything more than set the values for these slots. With :initform
arguments in the class definitions of all your classes you can create a standard bike
with make-instance on bike that in turn will make-instance on all of the constituent
parts!
(defclass bicycle (vehicle)
((wheels :initform (list (make-instance wheel) (make-instance wheel))
:accessor get-wheels)
(....other slots)))
Any customizing after just uses accessors to modify slot values.
(defmethod paint-bike ((bike bicycle) color)
(set-color (get-frame bike) color))
(defmethod set-color ((frm frame) color)
(setf (get-color frm) color))
You may want a standard 'part' class from which everything will inherit with slots for
cost, manufacturer, color, whatever matters in your world.....
| Imagine starting to construct a bike: Your start with tubes,
| make a frame, take some ball bearing, spokes and a rim, make a wheel,
| add the wheel to the frame, start with the next wheel, .... .
|
Well, bicycles are complicated! You just have to chose what it is that you need to
model. But with CLOS, i'm sure you'll always find an elegant way to model whatever
complications arise! (like adding a motor to your bike and having to change-class to
mo-ped ;-)
Coby
"see.signature" wrote:
> to clarify my earlier question about the IS-MADE-OF relationship:
> If i have a bike which is made of hundreds of individual parts (spokes,
> ball bearings, ...), that would mean that i need to put hundreds of
> object instances in the slot of bike? And how about taking a wheel
> away from the bike? Can i just dynamically delete a lot of slots from
> a bike object?
- Why delete a slot, how about just removing its contents?
> I think i am looking for a system which allows to manage the complexity
> of objects (e.g. a bike) which consist of a large number of parts
> (slots). The main problem is related to dynamically changing all these
> slots. Imagine starting to construct a bike: Your start with tubes,
> make a frame, take some ball bearing, spokes and a rim, make a wheel,
> add the wheel to the frame, start with the next wheel, .... .
Seems to me a little library research would be useful for you.
Plenty of stuff written about Artificial Intelligence after
about 1985 contains this kind of material. Look for frame-based
knowledge representation or semantic networks.
Various software would be available for example in the CMU AI
repository.
One interesting (non-CLOS) example would be the KR component of
the Garnet GUI system.
M.Halminen
From: Tim Bradshaw
Subject: Re: oo and made-of relationship in CL
Date:
Message-ID: <ey3d7o6rwno.fsf@cley.com>
* see signature wrote:
> If i have a bike which is made of hundreds of individual parts (spokes,
> ball bearings, ...), that would mean that i need to put hundreds of
> object instances in the slot of bike? And how about taking a wheel
> away from the bike? Can i just dynamically delete a lot of slots from
> a bike object?
If you want to do something like this you either want to have one
slot, say components, which has a list (or other collection) of
components, which you can then add from and delete at will, or you can
do some MOPpy stuff to create a class with dynamic slots which are
only allocated on demand.
If you have hundreds of objects which are substantively identical then
you probably want to use something like what the DP people call
singleton patterns -- objects with only one instance.
The problem in general sounds a lot like what the
knowledge-representation people do, so it might be interesting to look
at how they do it. Beware though that some of those people (not all,
I'm sure) write seriously awful Lisp.
--tim
In article <···············@cley.com>,
Tim Bradshaw <···@cley.com> wrote:
> * see signature wrote:
> > If i have a bike which is made of hundreds of individual parts
(spokes,
> > ball bearings, ...), that would mean that i need to put hundreds of
> > object instances in the slot of bike? And how about taking a wheel
> > away from the bike? Can i just dynamically delete a lot of slots
from
> > a bike object?
> If you have hundreds of objects which are substantively identical then
> you probably want to use something like what the DP people call
> singleton patterns -- objects with only one instance.
A singleton would still mean lots of slots, they would just all refer to
the same instance. If see signature really is modelling a bicycle then
they might be better off with a "set-of-bearings" class that contains,
say, a single bearing and a count of how many identical bearings there
are. There's no need to rigidly reflect real-life objects with software
objects (of course)...
Alternatively, there's a pattern in Design Patterns (can't remember the
name, but they talk about a letters in a document - you don't want that
many instances, just one instance for each different letter) that would
be useful if most bearings were the same, but not all (perhaps bearings
are either whole or chipped, for example...) (iirc it just generalises
the approach above).
Andrew
Sent via Deja.com http://www.deja.com/
Before you buy.
From: Fernando D. Mato Mira
Subject: Re: oo and made-of relationship in CL
Date:
Message-ID: <38E9E5EF.9CD30CA4@acm.org>
Andrew Cooke wrote:
> Alternatively, there's a pattern in Design Patterns (can't remember the
> name, but they talk about a letters in a document - you don't want that
> many instances, just one instance for each different letter) that would
Flyweight
--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
Andrew Cooke <······@andrewcooke.free-online.co.uk> writes:
> Alternatively, there's a pattern in Design Patterns (can't remember the
> name, but they talk about a letters in a document - you don't want that
> many instances, just one instance for each different letter) that would
> be useful if most bearings were the same, but not all (perhaps bearings
> are either whole or chipped, for example...) (iirc it just generalises
> the approach above).
Flyweight objects, if I remember correctly.
From: David Hanley
Subject: Re: oo and made-of relationship in CL
Date:
Message-ID: <38EA126A.CDD35977@ncgr.org>
"see.signature" wrote:
> Hi,
>
> to clarify my earlier question about the IS-MADE-OF relationship:
>
> If i have a bike which is made of hundreds of individual parts (spokes,
> ball bearings, ...), that would mean that i need to put hundreds of
> object instances in the slot of bike? And how about taking a wheel
> away from the bike? Can i just dynamically delete a lot of slots from
> a bike object?
>
> I think i am looking for a system which allows to manage the complexity
> of objects (e.g. a bike) which consist of a large number of parts
> (slots). The main problem is related to dynamically changing all these
> slots. Imagine starting to construct a bike: Your start with tubes,
> make a frame, take some ball bearing, spokes and a rim, make a wheel,
> add the wheel to the frame, start with the next wheel, .... .
Hmmm... I'm not sure how *exactly* one would do this ( I don't have
a CLOS guide handy.. ) but if I understand what you're looking for,
it seems possible to do this:
;an object which is composed of multiple onjects and delegates calls to them
(defclass composer () ( (composed-of :accessor composed-of)))
;add in an object that can be delegated to
(defmethod add ((c composer) object)(push object (composed-of c)))
;invoke that method on the first matching object
(defmethod invoke-first((c composer) method &rest args)
(let ((match (object-which-has-method (composed-of c) method)))
(when match
(apply method match args))))
;invoke this method on all the matching objects, returning all the results as a
list.
(defmethod invoke-all((c composer) method &rest args)
(mapcar #'(lambda(meth)(apply meth args)) (all-objects-with-method (composed-of
c) method)))
I just typed this right into the newsreader; I apologize for gross errors.
Obviously, more error checking should be done, and the object-which-has-method
needs to be written, but I don't think it's too hard.
(setq bike (make-instance 'composer))
(add bike (make-instance 'steering-wheel))
(add bike (make-instance 'drive-wheel))
(add bike (make-instance 'chro-moly-tube-frame))
(add bike (make-instance 'rapidfire-shifter-handlebars))
; maybe I should have add-object which takes a symbol, and calls make-instance on
; it for a shortcut.
(invoke-all 'subject-to-g-force-impact bike 5) ; call everything which has this
method.. they return 'ok or 'broken
(invoke-first 'subject-to-sweaty-hands bike) ; only relevant to handlebars.
There's a lot more you can do, like make rules allowing only one of certian
things, etc
david "let's see you do that in C++" hanley.
From: Friedrich Dominicus
Subject: Re: oo and made-of relationship in CL
Date:
Message-ID: <8766tyqjss.fsf@inka.de>
>>>>> "AC" == Andrew Cooke <······@andrewcooke.free-online.co.uk> writes:
AC> At the risk of muddying the water further, I would describe delegation
AC> as "forwarding a request initially directed to one object to another
AC> better able to handle it".
I would agree calling that delegation. And IMO that't what delegation is
about. :)
Regards
Friedrich
Friedrich Dominicus <···················@inka.de> writes:
>
> Yes, I just would not call it delegation
I think the term you are looking for is aggregation.
Chris.
--
http://www.double.co.nz/dylan
see.signature <······@No-Such-Domain.anywhere> wrote in message
·························@Flex111.dNWL.WAU.NL...
> This would allow a kind of construction of objects from basic "parts",
> instead of the classification type of relation used in the IS-A
> approach. Are there any lisp libraries implementing something like
> this or are there literature references?
Besides that standard OO-type constructs (class inheritance of IS-A and
slots for IS-MADE-OF relationships), many of the frame-based AI systems had
these constructs spelled out explicitly in the frame structures. There may
be a few of these systems found in the CMU AI Repository. These systems
will, generally speaking, dispatch messages between objects more slowly than
modeling the relations in CLOS.
faa
"Frank A. Adrian" <·······@uswest.net> writes:
>
> Besides that standard OO-type constructs (class inheritance of IS-A and
> slots for IS-MADE-OF relationships), many of the frame-based AI systems had
> these constructs spelled out explicitly in the frame structures. There may
> be a few of these systems found in the CMU AI Repository. These systems
> will, generally speaking, dispatch messages between objects more slowly than
> modeling the relations in CLOS.
>
> faa
>
See our contribution at gdl.sourceforge.net (the "gdl-base" module), which
is a "toy" implementation of the kind of declarative object syntax provided
in ICAD/IDL for modeling geometric parts (gdl doesn't define any primitive
geometric objects like ICAD/IDL, however - it is just a base language).
I think this implements something similar to what you are referring to
as well. The :parts construct creates either a single subpart or a
quantified aggregate, which gets instantiated on-demand and stored
in a slot of the parent class.
Personally I think of part-child relationships as a declarative
equivalent of function calls. You can think of a part object
as a pure functional object (takes inputs, computes outputs).
Sub-parts are merely a way of "calling" another function,
but it actually gets created as an object instance, so you
can call messages and methods in it more than once. Clearly
there is significant overhead to doing this as compared with
normal function programming with defuns. But in some cases
the advantages outweigh this overhead.
Once you've looked at gdl, gwl.sourceforge.net might also be of interest.
Yours,
-dave
--
David J. Cooper Jr, Chief Engineer Genworks International
·······@genworks.com 5777 West Maple, Suite 130
(248) 932-2512 (Genworks HQ/voicemail) West Bloomfield, MI 48322-2268
(248) 407-0633 (pager) http://www.genworks.com
On 04 Apr 2000 10:32:36 -0400, David J Cooper
<········@lang.genworks.com> wrote:
>See our contribution at gdl.sourceforge.net (the "gdl-base" module), which
>is a "toy" implementation of the kind of declarative object syntax provided
>in ICAD/IDL for modeling geometric parts (gdl doesn't define any primitive
>geometric objects like ICAD/IDL, however - it is just a base language).
>
After looking at gdl, i decided that this could be a possible way of
implementing the made-of realtionship in lisp. Thanks for the pointer.
Actually, when i was asking about the bike example, i was thinking
about a CAD like system, where each part of the bike has a seperate
identity, e.g. there are a lot of spokes, but they all have different
positions.
thanks,
Marc
--
------------------------------------------------------------------------------
email: marc dot hoffmann at users dot whh dot wau dot nl
------------------------------------------------------------------------------