> On Aug 7, 2018, at 10:56 AM, Alexis King <lexi.lam...@gmail.com> wrote:
>
> I guess I’ll take the bait and give the obvious-but-unhelpful answer,
> “Don’t use global variables.” :)
>
> I’m joking, but only just barely. It seems difficult to give concrete
> advice without knowing more details about your program and why you felt
> it was necessary to use global mutable state in the first place, so
> absent some reason why you need them, I have to recommend you just
> refactor your code to eliminate the globals. The standard techniques for
> writing testable code in other languages still apply in Racket, most
> notably dependency injection (aka “passing arguments to functions”).
> Racket also provides a few tools of its own for managing that kind of
> dynamic parameterization, such as parameters and units.
>
> Theoretically, an alternative solution would be to create a separate
> namespace (via racket/sandbox or otherwise) for each test file, allowing
> each test to use its own instantiation of the library. This almost
> certainly isn’t what you actually want, though, since real (non-test)
> clients of your library will bump into the same problem, and expecting
> them to do the same workaround is unreasonable. Indeed, I think the
> difficulty of testing an API like this means the the test suite is doing
> what it probably should: hinting that your API is hard to work with and
> needs to be changed.
>
> Alexis
Here’s a more concrete example:
Test-file-1
(require library)
(fact foo 10)
(fact bar 30)
(ans (? 30))
So the program collects facts and other prolog-like statement into the global,
then allows that data to be queried (similar to datalog, although I’m not sure
of datalog’s internals only its syntax and what it does). I suppose what would
be interesting would be some way of having the library understand what module
it is a part of and keep track of its data individually. I could probably do
that by replacing the globals with a hash table and since fact, and, etc are
macros I could grab the path /filename from the environment and pass that on to
the library…. parameters are something I’ve not played around with much, but
that’s something I’ll look into.
Kevin
--
You received this message because you are subscribed to the Google Groups
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
