From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27115 invoked by alias); 10 Nov 2013 20:04:11 -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: 31950 Received: (qmail 17717 invoked from network); 10 Nov 2013 20:03:56 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 From: Bart Schaefer Message-id: <131110120354.ZM21539@torch.brasslantern.com> Date: Sun, 10 Nov 2013 12:03:54 -0800 In-reply-to: <20131109223250.706e20fb@pws-pc.ntlworld.com> Comments: In reply to Peter Stephenson "Re: zsh 5.0.2-test-1 is available" (Nov 9, 10:32pm) References: <20131106202321.4a48c77b@pws-pc.ntlworld.com> <20131107153315.GW3544@sym.noone.org> <20131107160551.7aa195dc@pwslap01u.europe.root.pri> <20131107191806.GA85153@redoubt.spodhuis.org> <131107173627.ZM24325@torch.brasslantern.com> <20131108071627.GA6216@redoubt.spodhuis.org> <20131108093822.1534aa88@pwslap01u.europe.root.pri> <131108063903.ZM25660@torch.brasslantern.com> <20131108161109.6e373049@pwslap01u.europe.root.pri> <131108181143.ZM26121@torch.brasslantern.com> <20131109223250.706e20fb@pws-pc.ntlworld.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Errors on module feature [auto]loading (Re: zsh 5.0.2-test-1 is available) MIME-version: 1.0 Content-type: text/plain; charset=us-ascii [> workers] On Nov 9, 10:32pm, Peter Stephenson wrote: } } Suppose we load builtin bar from zsh/foo at some point, doesn't matter } how, then run "zmodload -a bar zsh/foo". We find that a builtin bar } exists. We can then check that zsh/foo is already loaded, and is } already providing builtin bar. And conversely we can tell that a builtin bar already exists that is not provided by zsh/foo ? This is the part that I thought for some reason was difficult. Where the analogy with autoloaded functions breaks down is that autoload for functions cannot be told which file the function must come from. It searches $fpath and takes the first one it finds. The autoload builtin makes the assumption (rightly or wrongly) that $fpath is stable and that if a function has already been loaded, it is the same one that would be found if $fpath were searched again. Loading of modules *themselves* with "zmodload zsh/foo" can make a similar assumption about $module_path so the analogy holds there. Explicit builtin autoloads with "zmodload -a zsh/foo bar" have no basis for making that same assumption. We've provided a way to say "bar must come from zsh/foo, even if zsh/bar would be found first by a $module_path search". Therefore, if we *can't* guarantee that bar came from zsh/foo, we should not suppress the error message. } furthermore, given that you can check by this means the effect really } *is* redundant rather than a conflict, it seems to me there is no } harmful side effect of any sort. I'm OK with this given the precondition. Do all the rules about warning on circular dependency, etc., apply? If I try to explicitly autoload from zsh/foo a feature that would implicitly be provided by zsh/bar, when if ever would an error occur? Aside: Should we update the manual to say that the right way to test for module existence is "zmodload -F module" (with no feature arguments)? This checks that the module could be loaded without enabling anything, whereas "zmodload [-i] module" enables all the default features. -- Barton E. Schaefer