Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!cme!cam!ARTEMIS
From: miller@GEM.cam.nist.gov (Bruce R. Miller)
Newsgroups: comp.lang.lisp
Subject: Re: Preserving case for LISP symbol names
Message-ID: <2856214136@ARTEMIS.cam.nist.gov>
Date: 6 Jul 90 00:48:56 GMT
References: <3186@stl.stc.co.uk>
Sender: news@cam.nist.gov
Followup-To: comp.lang.lisp
Organization: NIST - Center for Computing and Applied Mathematics
Lines: 50


In article <3186@stl.stc.co.uk>, Steve Perryman writes: 
> 
> 
> I have a problem which my lack of LISP knowledge prevents me from solving.
> 
> I have implemented a CLOS architecture which allows CLOS users to access
> Objective-C objects in a distributed environment. I have special CLOS objects
> which when called fail but since these objects override "no-applicable-method"
> as defined in the CLOS system, they request the objective-C service via the
> Internet. For example:
> 
> 
> Calling (objective_C_Op obj 1)    in CLOS 
> calls   [obj objective_C_Op: 1]   in Objective-C
> 
> 
> The problem is that the Objective-C method naming convention is case
> sensitive, and that the print value in LISP for the symbol objective_C_Op is

Wow! that's an interesting (and ambitious) idea!

But, how about a different approach to the problem?
Instead of defining a handler for no-applicable-method, which IMHO 
is a dangerous habit to get too comfortable with, why dont you define
methods for each of the functions which are `cross mounted'?

Or better yet, a macro such as

  (define-pseudo-method objective-c-op (args ..) "objective_C_Op")

which would expand to something like

  (defmethod objective-c-op (args)
     (network-magic args.. "objective_C_Op"))
[whatever Syntax; ok,ok i admit, i'm still a flavors programmer...]

This gives you the benefit of a documented, checked, etc, interface
and avoids making any assumptions about how lisp treats the case of
symbols, or whether any automatic re-casing mismatches the objective-c
code.

>  ...
> Thanks in advance,
> 
> Steven Perryman
> (skp@stl.stc.co.uk)

no problem;
bruce