Admittedly, macros so far have been 'with-' style macros that don't
take a lot of thought. But I just ran into a situation that led me to
try them in a new way, and I was amazed.
I wanted one package to have access to values from another, but I
didn't want to export/expose the variables. So, I decided to add
accessor functions and create a new 'interface.lisp' module.
I started out with this type of function:
(defun get-account-fwd (account-name)
(cond
((equalp account-name (name *account-1*))
(balance-fwd *account-1*))
((equalp account-name (name *account-2*))
(balance-fwd *account-2*))))
Then I realized I could try this:
(defmacro defaccgetter (fname sname)
`(defun ,fname (aname)
(cond
((equalp aname (name *account-1*))
(,sname *account-1*))
((equalp aname (name *account-2*))
(,sname *account-2*)))))
(defaccgetter get-account-fwd balancefwd)
and a few others like this one. I worked on the syntax to get it right
before I tried building and just confusing myself, and when I was
satisfied, I added all of these 'getters' to the package export list.
I was *stunned* when it compiled and ran *flawlessly*. No problem with
sequence of macro expansion, export of generated function names, or
anything. It was great.
One improvement I would like to make would be to use some kind of
iterating or looping form to go through all the slots of a specific
object and apply that macro to them and then export the result, so I
can add a new slot and have the cross-package-accessor function
automatically generated and even exported.
How might I approach this problem?
>I wanted one package to have access to values from another, but I
>didn't want to export/expose the variables. So, I decided to add
>accessor functions and create a new 'interface.lisp' module.
I don't understand what your macros are doing, but accessing variables
that aren't exported sounds rather easy.
Accessing exported variable:
mypackage:*exported-variable*
Accessing variable that is not exported:
mypackage::*internal-variable-that-you-shouldnt-touch*
If you are annoyed by the idea of encapsulation, in which a package
maintainer decides which variables you should or shouldn't touch, then
just use the double colon all the time. mypackage::*exported-variable*
works just fine.
"Eric Lavigne" <············@gmail.com> writes:
> If you are annoyed by the idea of encapsulation, in which a package
> maintainer decides which variables you should or shouldn't touch, then
> just use the double colon all the time. mypackage::*exported-variable*
> works just fine.
This will also keep you from getting annoyed when things work
correctly through package internals updates.
Zach
Zach Beane wrote:
> "Eric Lavigne" <············@gmail.com> writes:
>
> > If you are annoyed by the idea of encapsulation, in which a package
> > maintainer decides which variables you should or shouldn't touch, then
> > just use the double colon all the time. mypackage::*exported-variable*
> > works just fine.
>
> This will also keep you from getting annoyed when things work
> correctly through package internals updates.
Yes, this is the idea. I *could* access any variable from another
package, but if I make these accessors instead, then internal variable
name changes and/or implementation won't affect as much code in other
packages, if any.
This app started out with keyboard input, and I didn't care if a few
menu routines had access to the important objects and variables. In
fact, everything was in one package. Now that I've added another
package to make this a web app, the idea of clearly defined interfaces
makes it more maintainable.
>
> Zach
From: Thomas A. Russ
Subject: Re: Amazed by macros working on first attempt
Date:
Message-ID: <ymi4qaeu75f.fsf@sevak.isi.edu>
"jonathon" <···········@bigfoot.com> writes:
> One improvement I would like to make would be to use some kind of
> iterating or looping form to go through all the slots of a specific
> object and apply that macro to them and then export the result, so I
> can add a new slot and have the cross-package-accessor function
> automatically generated and even exported.
>
> How might I approach this problem?
Unfortunately, this one is a bit tricky, because standard ANSI Common
Lisp doesn't have a portable way of accessing slot information about
objects.
On the bright side, however, most Lisp systems now do implement at least
parts of the Meta-Object Protocol (MOP), and that provides a way of
getting the slot definitions of CLOS classes. You could use that as a
way of finding the slots to iterate across for CLOS objects. Whether
this would work for objects created by DEFSTRUCT, however, really
depends on the particular lisp implementation. But doing it for classes
should be sufficient for your purposes.
Take a look at http://www.lisp.org/mop/index.htm
--
Thomas A. Russ, USC/Information Sciences Institute
Thomas A. Russ wrote:
> Take a look at http://www.lisp.org/mop/index.htm
404. http://www.lisp.org/mop/index.html works, though.
--
Cameron MacKinnon
Toronto, Canada