On Mon, Jun 20, 2005 at 10:14:40PM -0500, Ken Williams wrote:
> Good observation, *but* if it's read-write then we need to propagate
> any modifications to the saved-state files in _build/. Otherwise, the
> user could change something in one action, or in the Build.PL code, and
> expect it to propagate to future actions, but it won't.
> One way to do that is to use the "persistent hash" class in Notes.pm,
> which I developed for this kind of thing (notes, config_data, cleanup,
> Or, maybe the user *wouldn't* expect that value to stick around. The
> model I've had in my head comes from "perl Makefile.PL FOO=BAR" and
> "make blah FOO=BAR", in which the former makes FOO=BAR for the entire
> build, but the latter makes FOO=BAR for just the "blah" target.
The trouble with that analogy is this isn't "perl Makefile.PL FOO=BAR" vs
"make blah FOO=BAR", its a whole new thing... the API. Are changes via
the API sticky? I'd punt and say "No, unless you say yes". Meaning, just
provide a "save" method to save the state of the current object. Let the
user decide. Its an API, it should be flexible.
Michael G Schwern schwern@... http://www.pobox.com/~schwern
'All anyone gets in a mirror is themselves,' she said. 'But what you
gets in a good gumbo is everything.'
-- "Witches Abroad" by Terry Prachett