This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Trouble understanding define (!)





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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]