From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6351 invoked from network); 6 May 2007 14:00:18 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.0 (2007-05-01) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=no version=3.2.0 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 6 May 2007 14:00:18 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 20499 invoked from network); 6 May 2007 14:00:07 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 6 May 2007 14:00:07 -0000 Received: (qmail 18475 invoked by alias); 6 May 2007 14:00:05 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 23394 Received: (qmail 18463 invoked from network); 6 May 2007 14:00:04 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 6 May 2007 14:00:04 -0000 Received: (qmail 19979 invoked from network); 6 May 2007 14:00:04 -0000 Received: from redoubt.spodhuis.org (HELO mx.spodhuis.org) (193.202.115.177) by a.mx.sunsite.dk with SMTP; 6 May 2007 14:00:01 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=first1; d=spodhuis.org; h=Received:Date:From:To:Subject:Message-ID:Mail-Followup-To:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To; b=dokO3ynW2xgxuJYLYPpmLEZFkU/pHYjzLa4Hae2YoGB4Vj6AB+xDBkJkadhLew8sYohhDLyBS8ps1gCzYW5oIAZiNfoxxz8BPp7EOS78svLHa5ZjXOtv2Z0Nbx54Vlw9Ft3m6kYvTdlC4M/u6gE/+UnDm5nYcoZFbIQuuAdfs94=; Received: by smtp.spodhuis.org with local id 1HkhHM-000Kwn-MI; Sun, 06 May 2007 14:00:00 +0000 Date: Sun, 6 May 2007 07:00:00 -0700 From: Phil Pennock To: zsh-workers@sunsite.dk Subject: Re: [PATCH] Proposal: stat -> zstat Message-ID: <20070506140000.GA80030@redoubt.spodhuis.org> Mail-Followup-To: zsh-workers@sunsite.dk References: <20070506010750.GA46162@redoubt.spodhuis.org> <200705061157.l46BvISQ003772@pwslaptop.csr.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200705061157.l46BvISQ003772@pwslaptop.csr.com> On 2007-05-06 at 12:57 +0100, Peter Stephenson wrote: > I'd still prefer a general solution along the lines of the feature > mechanism, which requires (as far as I can see) no kludging or removal > of anything, but I have had absolutely no response to that. Well, I like it. FWIW. Sorry, kept quiet because I couldn't see anything wrong with the idea and I wasn't volunteering to do the coding. ;-) Oh, and because I've been contaminated by Perl so I'm use to: use Foo::bar qw/:DEFAULT :wibble -froz/; so your proposal fits neatly with my mental models and is actually simpler, since it doesn't have tagged groups of things to enable/disable. Except insofar as the features-named-with-conventions would let you do just that. Is it worth adding to the spec that the features will be processed left-to-right, so that interactions between features will work? Eg, disable all except certain aspects? Most modules will never use this, thankfully. zmodload -F zsh/pcre -:builtins :condops zmodload -F zsh/files :files -mv :fs (hypothetically putting "sync" in an ":fs" category) And yes, the : as a part of the name instead of a separator is distinctly un-shell-like, I use it here only so that those similarly afflicted will understand what I mean. On the other hand, arguing devil's advocate, what would the feature infrastructure provide that's not already available via zsh/parameters and use of enable/disable? Perhaps, evil thought, if feature-set changes could be tied to a function in the same way as localoptions lets you emulate ... then this would definitely provide cleaner start-up and functions could then just explicitly declare their dependencies .... how much overhead would there be for this? I'm not sure how much complexity this introduces for little gain.