Logically you can extend data-driven programming to storing opcodes with parameters in a database, and writing an interpreter in any language. That's a valid approach under some circumstances, in fact (see my article on this topic at http://www-128.ibm.com/developerworks/linux/library/l-cpdata.html).
The trick with data-driven programming, just like OOP or any other paradigm, is knowing how much is enough to get the job done. My overriding maxim has always been "if you have to do it more than twice, it's worth abstracting." So for example, if you have this kind of code: retrieve user A modify user A store user A retrieve user B delete user B I wouldn't abstract things yet because a) it's too much hassle in terms of code and documentation, and b) it's more readable this way. But when you add retrieve user C modify user C store user C I immediately abstract it into do_user(USER[], OPERATIONS[][]) Ted _______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
