The thing that was being mentioned by someone's earlier email was something to the effect of using look up tables to handle control logic, and keeping the script constant while changing the data as the spec evolves. The approach has a familiar ring to it. If I actually have a good day of coding, I'll hand off as much control functionality to the user rather than trying to put it into my script. The idea being to keep the same capability of functionality, but leaving as much as possible to be controlled by the user and the data they feed my script, rather than having hard coded control structures in my script. I don't know how to summarize this approach in a one-liner, though. Perhaps something like "put the control functionality into the users data, not your script" I haven't been able to consistently implement this and it seems to be some vague principle I've learned the more I code, rather than something I learned in school or in a programming book or whatever. I failed to do this in one of my recent big scripts and implemented a code generating script by parsing a text config file from the user. As the config file got more and more complicated, I realized that I should have had the user write the configuration file in the form of a perl script and provide a code generating module that they use. my bad. If I were to create a maxim, it would be something to the effect that if you need to give your user control of your script through LUT's and other data, then consider whether you should give them a module and have them do their control logic in perl.
as your control LUT's and data structures get more complicated, it might become easier to leverage perl to handle that, rather than having the user munge more and more complicated data structures ________________________________ From: [EMAIL PROTECTED] on behalf of Charlie Reitzel Sent: Wed 4/5/2006 10:18 AM To: Tolkin, Steve Cc: boston-pm@mail.pm.org Subject: Re: [Boston.pm] Put similarities in code and differences in data Sorry, I can't give you a reference. It is something I first learned from an Oracle consultant back in '87 and have since embraced and extended to many different environments - including Perl. That said, most 4GL tools worthy of the label implement this idiom. Think PowerBuilder, et al. Another way to look at it is "data dictionary driven development". If, in your data model, you have enumerated types, then it makes sense to provide flexibility in defining the value domain of those types. Moreover, just as we have UI tools for currency, numeric, date and time values, it makes sense to support enumerated types as well. Nothing dramatic here. Naive implementations of enumerated types tend to give each domain its own unique table and database constraints, model and view classes, etc., etc. This is just overkill. By stepping up one level of metadata, you can treat enumerated types in a much more general way. Of course, as usual, Uri is right. There is no magic bullet for hiding complexity. But that isn't really what this technique is about. Rather, by simply dealing with enumerated types as such, it reduces the complexity without making the code look like an interpreter. At 09:55 AM 4/4/2006 -0400, Tolkin, Steve wrote: >Thank you Charlie. That is the idea I am trying to get across. Do you >have any suggestions about how to get developers to see the benefits of >writing programs this way? Any specific books, techniques, etc.? Any >pitfalls to be aware of? > >Thanks, >Steve > > >-----Original Message----- >From: Charlie Reitzel >Sent: Tuesday, April 04, 2006 9:18 AM >Subject: Re: Put similarities in code and differences in data > > >Not really. I believe it is intended to mean "data driven programming" >as Jeremy mentioned earlier. To me, data driven programming means "use >lotsa lookup tables, the contents of which are user tweakable". As simple as >it sounds, it can be an effective technique to let you quickly adapt a >system as requirements "evolve" - without code changes. > >Having found this hammer early in my programming career, I find a great >many nails. Early days in any new design are spent setting up a "lookup > >table" table, along with utility routines for reporting, validation, UI >picking values (one or several), etc. > >It may be a use case, but I don't think this is quite the same thing as >the subject of this thread which, as Uri says, is a general approach to >analysis. > >At 09:00 AM 4/4/2006 -0400, [EMAIL PROTECTED] wrote: > >( 06.04.04 08:46 -0400 ) Tolkin, Steve: > > > The difference is that I am trying to find a quote that > > > focuses on the benefits of using data in a special way, > > > as "control data", to determine > > > the specific execution path taken by the code. > > > >um, isn't this the scientific method? _______________________________________________ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm _______________________________________________ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
