Hello. I've a stylistic or "paradigm/pattern" question regarding how one
correctly designs inter-package interfaces. Our application contains a
"stand-alone" package that implements some CORBA services. From our
software's "primary" package, I want some code to run whenever a
particular CORBA service receives a request. A concrete example would
help here:
Package INFM_SERVICES (nickname IF) implements the CORBA services.
Within this package is a class QUERY-SERVER that receives a request but
by default doesn't know what to do with it; each request must be
evaluated somehow, perhaps either via a "callback" or a method that
specializes on QUERY-SERVER. Now, here is package INFM. I need the
"callback" or method invoked by QUERY-SERVER to run within INFM's
context (i.e. within package INFM). The following example does *not*
work because it runs within the context of package IF:
(in-package "INFM")
(defmethod if:run-query ((self if:query-server) query)
(operate-on-query query))
Somehow, I need to be able to change the package within the scope of
method RUN-QUERY, so I did the following:
(defmacro with-package ((pkg) &body body)
`(let ((*package* (find-package ,pkg)))
,@body))
(defmethod if:run-query ((self if:query-server) query)
(with-package ("INFM")
(operate-on-query query)))
This works, but is it "proper Lisp style"? Our software follows the "as
few packages as possible" paradigm, but in this case I'm wondering if
this manipulation of the special variable *PACKAGE* is a BAD THING, or
if the general approach (separate package for CORBA services) is itself
flawed. There seemed to be a good reason to separate IF from INFM, as we
were running into symbol collisions when the CORBA stuff lived in INFM.
I'd appreciate your thoughts.
--
-----------------------------------------------------------------
David E. Young
Fujitsu Network Communications "The fact that ... we still
(········@computer.org) live well cannot ease the pain of
feeling that we no longer live nobly."
-- John Updike
"Programming should be fun,
programs should be beautiful"
-- P. Graham
* David E Young wrote:
> Package INFM_SERVICES (nickname IF) implements the CORBA services.
> Within this package is a class QUERY-SERVER that receives a request but
> by default doesn't know what to do with it; each request must be
> evaluated somehow, perhaps either via a "callback" or a method that
> specializes on QUERY-SERVER. Now, here is package INFM. I need the
> "callback" or method invoked by QUERY-SERVER to run within INFM's
> context (i.e. within package INFM). The following example does *not*
> work because it runs within the context of package IF:
Can you explain *why* you need to do this? Are you calling intern or
something which is putting stuff in the wrong package?
--tim
Tim Bradshaw wrote:
> * David E Young wrote:
> > Package INFM_SERVICES (nickname IF) implements the CORBA services.
> > Within this package is a class QUERY-SERVER that receives a request but
> > by default doesn't know what to do with it; each request must be
> > evaluated somehow, perhaps either via a "callback" or a method that
> > specializes on QUERY-SERVER. Now, here is package INFM. I need the
> > "callback" or method invoked by QUERY-SERVER to run within INFM's
> > context (i.e. within package INFM). The following example does *not*
> > work because it runs within the context of package IF:
>
> Can you explain *why* you need to do this? Are you calling intern or
> something which is putting stuff in the wrong package?
>
> --tim
Actually, we go out of our way to isolate things well; we don't have an
errant INTERN. We're using a very nice third-party system that interns
symbols into package INFM; that's just the state of the world. The trouble
occurs when we write our CORBA methods in INFM; some symbols collide with
ones that live in the third-party software imported into INFM. I could
certainly choose different symbol names and avoid the collision, but this
seems to skirt a larger software maintenance issue. I'm wondering how other
Lisp developers have approached this issue.
--
David E. Young
Fujitsu Network Communications "The fact that ... we still
(···@nc.fnc.fujitsu.com) live well cannot ease the pain of
feeling that we no longer live nobly."
-- John Updike
"Programming should be fun,
programs should be beautiful"
-- P. Graham
I think it is fine style.
I assume that there is some form of READing going on in the query
processing. Otherwise it would be difficult to see why binding
*package* would be necessary. If you do need to read, then you will
need to make sure that it is done in the proper environment.
My only suggestion would be to have your WITH-PACKAGE macro signal an
error if the requested package can't be found, since binding *package*
to NIL could make debugging a bit difficult.
--
Thomas A. Russ, USC/Information Sciences Institute ···@isi.edu
"Thomas A. Russ" wrote:
> I think it is fine style.
>
> I assume that there is some form of READing going on in the query
> processing. Otherwise it would be difficult to see why binding
> *package* would be necessary. If you do need to read, then you will
> need to make sure that it is done in the proper environment.
>
Yes, indeed. We're invoking READ -FROM-STRING on a variable containing a
LOOM query.
>
> My only suggestion would be to have your WITH-PACKAGE macro signal an
> error if the requested package can't be found, since binding *package*
> to NIL could make debugging a bit difficult.
>
Certainly. A good idea. Thanks very much.
Regards,
--
David E. Young
Fujitsu Network Communications "The fact that ... we still
(···@nc.fnc.fujitsu.com) live well cannot ease the pain of
feeling that we no longer live nobly."
-- John Updike
"Programming should be fun,
programs should be beautiful"
-- P. Graham