[asdf-devel] Enforcing pure *.asd files

Robert Goldman rpgoldman at sift.info
Thu Mar 18 22:18:18 UTC 2010


On 3/18/10 Mar 18 -5:11 PM, Juan Jose Garcia-Ripoll wrote:
> On Thu, Mar 18, 2010 at 10:47 PM, Faré <fahree at gmail.com
> <mailto:fahree at gmail.com>> wrote:
> 
>     What about instead investing in XCVB?
> 
> 
> As much as I would like to have something simplify my life, it is not my
> choice to use one system or another. I was suggesting something that
> might help rationalize the current library situation.
>  
> 
>     Such enforcement will necessarily introduce backward incompatibility
>     and pain,
>     which I think goes contrary to the goals of ASDF.
> 
> 
> I am not talking about something that HAS to be enforced, but that it
> can be optional. It is by no means a good coding practice to put things
> in the *.asd file that do not belong in it. Promoting this message from
> the ASDF development forum is not wrong by itself and need not cause any
> pain at all -- a warning message somewhere in the build, explaining the
> situation of the libraries in the system does not cause such a panic or
> disrupture, does it?

Right.  But do we have a clear understanding of what should and
shouldn't go in there?  E.g.:

1.  currently if you need an ASDF extension in order to make a defsystem
understandable (e.g., we have an extension that provides a new SYSTEM
subclass to fit with our testing library), then you must put

(asdf:oos 'asdf:load-op <my extension>)

in the .ASD file, and this is undesirable, I agree, but there's no
workaround.

2.  New class and method definitions.  We don't have a good way to put
them anywhere /but/ the .asd file for now.

I see the point about good coding practice, but I feel weird about
telling people to use good coding practice at the same time telling them
they have to use bad (non-declarative) coding practice, because there's
no alternative!

Can you say more about what you'd like to do specifically?  I don't want
to discourage you from providing support for the sad lot of ASDF system
definers ;-)!




More information about the asdf-devel mailing list