On Friday, August 3, 2018 at 1:24:08 AM UTC+8, johnbclements wrote:
>
> I hate to turn a little question into a big one, but… are parameters the
> right choice, here? It seems to me that optional parameters would be more
> suitable.
>
Most (but not all) parameters act as default values for renderers, so you
can
use either style:
(plot (list (function sin #:width 5) (function cos #:width 5))
#:x-min -5 #:x-max 5)
(parameterize ([line-width 5])
(plot (list (function sin) (function cos))
#:x-min -5 #:x-max 5))
However, the bug in the plot package is more simple and can be illustrated
by
this code:
#lang racket
(define p1 (make-parameter #t))
(define (foo)
(printf "p1: ~a" (p1)))
(define bar
(parameterize ([p1 #f])
(lambda ()
(foo))))
Calling `(bar)` will not print "p1: #f", even tough it does appear to have
been the intention... To my defense, in case of the plot package, the code
is
a bit more complex and it is not immediately obvious that the above case was
happening.
Alex.
>
> Unfortunately, I’ve been on the other side of this fence, too: parameters
> are vastly more convenient for implementors than adding optional parameters
> to every one of the internal calls. This certainly came up for me in the
> construction of a CSV writing library.
>
> I can imagine a bunch of programming patterns that might assist this; the
> most obvious one would be an object-like metaphor where parameter values
> are represented as an object to which calls are made. Do others have ideas
> on a “best practice” for this situation and others like it?
>
> John
>
>
>
>
>
>
--
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.
