[racket] Saving and restoring many parameters

On Wed, Oct 19, 2011 at 12:39 PM, Neil Toronto <neil.toronto at gmail.com> wrote:
> On 10/19/2011 10:31 AM, John Clements wrote:
>>
>> On Oct 19, 2011, at 9:29 AM, John Clements wrote:
>>
>>>
>>> On Oct 19, 2011, at 4:03 AM, Robby Findler wrote:
>>>
>>>> (I'm sorry if you got this message already; I thought I sent it
>>>> already but I don't see it.)
>>>>
>>>> What about the current-output/error-port? what about the
>>>> current-namespace? current-custodian?
>>>>
>>>> There are lots of parameters that affect core functions in subtle ways
>>>> and if you do something like this in plot, it seems like it could lead
>>>> to serious confusion someday. Also, it can introduce leaks.
>>>
>>> +1. I think this is not not not a good idea.
>>>
>>> Robby's solution requires you to make one list of all of the plot-related
>>> parameters, which looks to me like the "right" amount of work.
>>>
>>> Furthermore, it has the unpleasant characteristic that when it breaks, it
>>> will be exposed in an unwanted change to a parameter that will likely be
>>> entirely unrelated to plot. Tracking this down will be horrible, and the
>>> axe-wielding murderer of legend will be very unhappy when he (or she?)
>>> finally gets to your doorstep.
>>
>> Dangling pronoun. Of course, I meant to say
>>
>> "Furthermore, [your solution] has the unpleasant characteristic..."
>
> Look, as long as it's not Richard Stallman with the ax...
>
> If I spawn a render thread that inherits the parent thread's parameters,
> won't things like current-namespace and current-custodian have the right
> values?
>
> It's starting to look like that is the solution that is the most
> maintainable and the least work. And it still allows users to parameterize
> the functions they plot. If something breaks, it's not my fault, because
> spawning a thread that waits on a channel for a "draw now!" command, and
> then draws on a dc, should just work, right?

In either case, it will be equally likely to be your fault.

The issue will be if the drawing call back expects parameters to be
set in the context in which the actually calback has.

Which they might. Maybe.

Robby