Re: Possibly excessive WARN_CREATE_GLOBAL

[Peter Stephenson <p.stephenson@samsung.com>]

On Mon, 23 Nov 2015 20:43:51 -0800
Bart Schaefer <schaefer@brasslantern.com> wrote:

 On Nov 23,  3:49pm, Peter Stephenson wrote:
> } Subject: Re: Possibly excessive WARN_CREATE_GLOBAL
> } Being special and removable shouldn't stop you re-enabling the parameter
> } --- this test has nothing to do with scope here, it's just recreating
> } the parameter as you've asked it to do.  (It's not checking PM_HIDE here,
> } or you might think that was useful.)
> 
> It took me a while to figure out how to explain why I think this is
> dubious, but finally decided it comes down to this:  Toggling PM_UNSET
> off here without calling the GSU setfn implicitly provides a default
> value for the parameter, which is sort of OK for normal parameters but
> wrong for PM_SPECIAL.  If nothing else, it means the getfn has to be
> prepared to return something even if the setfn has never been called.

I think we're over a barrel here: on the one hand, whether a parameter
is set or unset is a generic property that naturally gets managed at
this point, while for a special preparing a value to return is a highly
specific matter.  I don't think we could do this much better without
upgrading the interfaces somewhere around these lower levels.

The best we could do, perhaps, is enforce a rule that a special that's
set is required to return something sensible (not necessarily useful)
even before a value has been passed in.  A lot of specials probably
already respect this --- we fixed problems in the distant past with
nulls appearing where we didn't want them, I seem to remember.

> } Perhaps what it should be doing is creating a new one in the inner
> } scope that hides the private one as the least bad effect.
> 
> What should happen is that it creates a new one at global scope, and
> trips warncreateglobal if necessary.  Which DOES happen if the one at
> global scope was previously assigned and/or explicitly declared.  The
> difficulty only arises when the private parameter is at the outermost
> scope where any parameter of that name can be found.

OK, I'm missing the fact that usually the private stuff keeps well out
of the way of whatever else is going on, hence its name, except for some
slightly suspect interactions with a previous parameter at this point.

pws