Advice on: sharing data between stacks

[Alex Tweedly]

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