From: Joachim Kock (kock@math.unice.fr)
Date: 12 Mar 01, 09:43 EST
From: Joachim Kock <kock@math.unice.fr> Subject: flags versus features 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