|
From: Andrew T. <an...@tr...> - 2008-08-29 23:19:18
|
Tom: > Or just make it a totally separate class, either copying or referencing > the color and icon data hardcoded in JvnAlgo. Surely no need to do that. Tim's mod is clearly related to JvN's CA so best to keep it in jvnalgo. I definitely think it should be included in the next release. I'm not quite so keen on "modJvN-32" for the rule -- perhaps it's time to change the 3 canonical rules to something like JvN, EJvN and MJvN (setrule could still recognize the old rule strings). Not really important though -- I'm happy to go with whatever rules Tom/Tim/William prefer. > Andrew, I think we're going to get a *lot* of things like this from various > people, and we need to start making hard decisions on what to include, > how to include things, and so on and so forth. If people provide mods that look interesting (and work!) then I'm all for including them. My only concern is that we don't end up with dozens/hundreds of new algos. I'd prefer to see Golly support a reasonably small number of algos (less than 20?), some of which allow many different rules (like qlife/hlife/generations). > Or else provide some extension mechanism. By that I assume you mean dynamic algo loading via plug-ins? If so, yes, we should definitely aim for that. I think the current design is a useful intermediate stage on the way to that goal. It should provide valuable ideas for what we'll need to include in any eventual plug-in interface. Andrew |