From: Vince Darley (vince@santafe.edu)
Date: 12 Mar 01, 21:47 EST
From: Vince Darley <vince@santafe.edu> Subject: Re: flags versus features I strongly agree with all of this. We've tried over the last couple of years to do this with a lot of the core code. Things like backup, filesets, etc are entirely separate pieces of code now. For 'twiddle' one could argue either way. One issue is that the code is so simple (even with a variety of options) that it seems crazy to have one default procedure and then a feature which implements a new version which is only marginally more complex. Another approach might be to strip out all of the twiddle stuff from the core and move it to a feature (perhaps one which is automatically on). Then both the twiddle procs and their preferences would all be in one file. There is a lot of core stuff which could be moved like this. It might even be good to formalise the core's notion of 'CorePackages' so that it contains these things. Any thoughts? cheers, -- Vince <http://www.santafe.edu/~vince> On Sun, 11 Mar 2001, Joachim Kock wrote: > Hello developers, > > sorry for bothering you all with these reflections --- > > It seems to be characteristic for today's alpha development to > introduce options and preferences for everything. Of course this > devotion to satisfying everybody is admirable, but I think you will > agree that it has disadvantages as well: it complicates the programme, > and important flags tend to disappear among secondary options, and > the code becomes less readable. > > (If you go to a procedure definition to change something, you find > flags and switches like 0, 1, 2 - what do they mean? well, the user > checked a check-box in some dialogue, and some secondary dialogue > handling procedure wrote a 0, 1, or a 2 in a global variable). > > One could consider another approach, which is surely less democratic, > but could render alpha more elegant, and perhaps more robust... > Instead of including those options in the distributed code, the > alternatives (space-ignoring twiddle, select-shrinking as default, > etc...) should be uploaded to a web site as alpha features with an > installer and reasonable documentation (and the e-mail address of the > developer). (Please check out 'Extending Alpha...') > > The user who needs the alternative behaviour can install the feature > at his own risk (and never blame alpha for bugs). The installer > should not overwrite code but use an overriding scheme like > smart-source. In this way the user can always 'restart alpha with > extensions off' if he experiences buggy behaviour... > > As you see, this is in the vein of MacOS. Alpha has fine support for > all this, it is only a question of using it! > > The simplicity resulting from a more consequent use of features > instead of flags would make Alpha easier to use and modify (the novice > user can simply forget about these add-ons; the tcl-minded user can > easier read the code; and those who feel strongly about twiddling or > cursor-philosophies will gladly go to the website to find realisations > of their dreams --- this is probably much easier than wrestling with a > mob of conservative alphatcl'ers on alpha-d). On the other hand, > alpha would be easier to maintain and develop: our core developers can > concentrate on essential issues, instead of fiddling with twiddling. > A lot of trouble would be passed on to extension writers... > > Surely, as it may happen, some extensions are so obvious that they will > sooner of later find their way into the distributed code, as the menu > clock inevitably found its way into MacOS after many years as a > separate extension. > > > > Cheers, > Joachim. > > ---------------------------------------------------------------------- > Joachim KOCK > Laboratoire de Mathématiques J.A.Dieudonné Tél. +33 04.92.07.62.40 > Université de Nice Sophia-Antipolis Fax +33 04.93.51.79.74 > Parc Valrose - 06108 Nice cédex 2 - FRANCE Mél. kock@math.unice.fr > ---------------------------------------------------------------------- > > _______________________________________________ > AlphaTcl-developers mailing list > AlphaTcl-developers@lists.sourceforge.net > http://lists.sourceforge.net/lists/listinfo/alphatcl-developers > _______________________________________________ AlphaTcl-developers mailing list AlphaTcl-developers@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/alphatcl-developers