Emilio Gagliardi wrote:
>This sounds like you'll (potentially) finish up with a custom stack for
>each child (or grandchild)
Correct.
>I'd worry this could lead to code
>duplication between all these stacks. Could you not simply store data
>specific to that child, with a central set of custom stacks for
>different categories.
I'm not sure I understand what you mean by central set of custom stacks.
Yes there will be duplication but that is fine, so long as the
demographic data is passed correctly to the sub stack and the sub
stack correctly passes out the data to write to file. The reason
this is necessary is because we need to write the sub stacks very
quickly and usually with a very restricted range of functionality
that is independent of all other sub stacks. further, not everyone
who creates the sub stacks is a serious programmer so i wanted a
system that is flexible and loose.
I try to avoid writing code whenever I can :-)
I try to write code that it (relatively) general, where the data can
modify the results.
You described this as "substacks are very simple, limited range of
functionality and can be written quickly by people who are not serious
programmers". To me, that suggest that it would be possible to write a
sub-stack that would be general enough to handle not a single
individual, but a class of them - with only specific data varying
between the individuals. Then (in some cases, not all) there would be no
need to write any new substack - you'd simply provide the data needed to
drive that slightly more general sub-stack,
by "a central set of custom stacks" I was think it might be possible to
write a number of stacks - each with a certain level of generality. I
have no idea what might be relevant to your problem - but maybe
something like:
- one substack for female adult
- one for female teenager
- one for female child
- same three for male ....
The main reason to avoid writing, and replicating, code is that when
(not "if") you discover a bug in the code you have been writing, you
don't need to go and change many replicated instances of it - you change
the code in one place; the other main reason is that (if you can get
enough generality) you can avoid the need to write any code for each
additional person in your database - so it gets easier for
non-programmers to do so.
--
Alex Tweedly http://www.tweedly.net
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.323 / Virus Database: 267.6.2 - Release Date: 04/06/2005
_______________________________________________
use-revolution mailing list
[email protected]
http://lists.runrev.com/mailman/listinfo/use-revolution
