From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 682 invoked by alias); 24 Nov 2015 10:41:28 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 37210 Received: (qmail 10801 invoked from network); 24 Nov 2015 10:41:24 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 X-AuditID: cbfec7f5-f79b16d000005389-a0-56543ed19113 Date: Tue, 24 Nov 2015 10:41:18 +0000 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: Possibly excessive WARN_CREATE_GLOBAL Message-id: <20151124104118.4d5a1f53@pwslap01u.europe.root.pri> In-reply-to: <151123204351.ZM23160@torch.brasslantern.com> References: <201511221915.tAMJFbFW006908@localhost.localdomain> <151122123028.ZM11174@torch.brasslantern.com> <20151123154916.7ef3406e@pwslap01u.europe.root.pri> <151123204351.ZM23160@torch.brasslantern.com> Organization: Samsung Cambridge Solution Centre X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.0; i386-redhat-linux-gnu) MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsVy+t/xK7oX7ULCDKbeZrM42PyQyYHRY9XB D0wBjFFcNimpOZllqUX6dglcGU/+b2Ms6BGq2DTlL1sD43a+LkZODgkBE4nu6w8YIWwxiQv3 1rN1MXJxCAksZZS48mQ5K4Qzg0nidMt2qMw5Romji/ZBOWcZJV6uvsDSxcjBwSKgKtE93QRk FJuAocTUTbPBxooIiEucXXueBcQWFjCS+H79LJjNK2Av8XLXNXYQm1PASmLa2U1QM68ySnzs Xc8EkuAX0Je4+vcTE8R99hIzr5xhhGgWlPgx+R7YIGYBLYnN25pYIWx5ic1r3jKD2EIC6hI3 7u5mn8AoPAtJyywkLbOQtCxgZF7FKJpamlxQnJSea6RXnJhbXJqXrpecn7uJERLQX3cwLj1m dYhRgINRiYf3Q0lwmBBrYllxZe4hRgkOZiURXmv9kDAh3pTEyqrUovz4otKc1OJDjNIcLEri vDN3vQ8REkhPLEnNTk0tSC2CyTJxcEo1MGpKfLVw3f636nb8Sa3PFt3qO/l/7hKWnprpbyxW Hy27jG3W39qKml/dm45JWt8NunXdnNPh/J53wvvTw7zLP4dMuxa36zFX6fqtdr823nL69PBT TAi/21Met8+iFUbz+dh94mxnWUt/NnUxFHPVey7Z+fDy4dgt0zTX8W8+GnvjcvIf6eCfTEos xRmJhlrMRcWJAGInTB5kAgAA On Mon, 23 Nov 2015 20:43:51 -0800 Bart Schaefer 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