This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: Trouble understanding define (!)
- To: Ken Anderson <kanderso at bbn dot com>
- Subject: Re: Trouble understanding define (!)
- From: Jost Boekemeier <jostobfe at linux dot zrz dot TU-Berlin dot DE>
- Date: 04 Feb 2000 00:50:44 +0100
- Cc: Mikael Djurfeldt <mdj at mdj dot nada dot kth dot se>, Michael Livshin <mlivshin at bigfoot dot com>, Neil Jerram <neil at ossau dot uklinux dot net>, guile at sourceware dot cygnus dot com, amp-developers at bbn dot com
- References: <Michael Livshin's message of "30 Jan 2000 18:17:18 +0200"> <200001142054.UAA00622@ossau> <p2tzou4o5ov.fsf@pampelmuse.zrz.tu-berlin.de> <200001182250.WAA00624@ossau> <xy7ya9nezzz.fsf@mdj.nada.kth.se> <200001221200.MAA00478@ossau> <xy7bt6e82ru.fsf@mdj.nada.kth.se> <s3zotxrqoz.fsf@verisity.com> <xy7iu0cbc1z.fsf@mdj.nada.kth.se> <s3iu0bq1x5.fsf@verisity.com> <xy71z6z35os.fsf@mdj.nada.kth.se> <s33drfpm9d.fsf@verisity.com> <3.0.3.32.20000203164343.00955d10@zima.bbn.com>
Ken Anderson <kanderso@bbn.com> writes:
> While i'm not completely up on your discussion, i can provide some CLOS perspective.
>
> Kiczales' paper is definitely worth reading.
> http://www.parc.xerox.com/csl/groups/sda/publications/papers/Kiczales-OOPSLA92/
I'll look at it again. You may find this arrogant but I don't trust
Lisp/Scheme people at all. They write tons of papers describing
problems that have been solved and promote what they think are
unique solutions.
> I know several CLOS programmers, including myself who were suprised
> to find out that in Java or C++ instances of the same class can
> invoke private methods on each other. Is there a good reason for
> this besides convenience?
Good question. AFIK eiffel has per-object encapsulation but I am not
sure at the moment.
> Part of being a generic function is that methods can be added to
> you. The easiest way to do this is to have a name, as CLOS more or
> less requires. Names conflict as you point out, and modules systems
> help up to a point.
Yes.
> In Tiny CLOS you can have anonymous generics but somehow they still
> need to find each other.
Interesting. Could you please give an example of how they are used?
> Use the module system to carefully merge names and resolve conflicts
> like (draw) by hand
These conflicts happen, but as I understand it the methods of GF's are
always unique. In pseudo-code:
class <point> class <cicle>
defmethod draw <point> defmethod draw <cicle>
defmethod draw <line> <int> defmethod draw <line> <int>
defvar state 99 defvar state 100
We have two classes and one GF "draw" with four different methods (or
two distinct GF which will be merged as soon as you inherit from both
point and cicle, as I've pointed out in some other posting, but this
is an implementation detail). Where do you see problems?
You will have problems when you want to inherit from both point and
cicle. But this is a standard problem (connected with multiple
inheritance) and can be solved by re-ordering the class precedence
list or by feature renaming (which eiffel has). I think re-ordering
is more CLOS'isch. :9
Of course, the module system traces locations and knows wether the
locations belonging to the two state (or draw) variables above are
distinct or not.
If here's a problem, I still fail to see it.
Jost