On Sep 15, 2009, at 5:44 PM, Matt Brooks wrote:
> Thank you for everyone's input, I am thinking about it all right now,
> and hope to have a combined solution tomorrow.
>
> I have to figure out how to make a Signal Object, i can't see how I am
> going to get around having this messed up hash problem even if I  
> make a
> signal object. because of the repeating fields within the data.
>
> I think having objects only changes the fact of instead of having an
> array of hashes at my top level, i have an array of objects that have
> hashes inside of them anyway...  I have hundreds of variables for each
> signal, and I can't make this signal object have 200 local  
> variables, I
> think it would be dirty to type
> attr_reader: for all the hundreds variables...

Consider what a Hash is: a special mapping of keys to values with the  
restriction that a key can only appear once. Why not represent the  
data not as a {'key'=>'value'} but as ['key','value']? Unless the  
performance optimization of the Hash lookup is truly important. You  
can then use things like Array#assoc to get the pair back.

>
> Plus then only some of them get defined each time...
>
> Am I thinking about this correctly?  i have seen that tutorial, i  
> think
> actually in my book here by Peter Cooper or at least something  
> similar,
> although I am not seeing how it relates fully.
>
> Thanks!!!
> Matt
> -- 


You get the ordering (which is what comes to my mind when you say  
"repeating fields") of an array, but your have pairs rather than  
simple scalar values.

-Rob

Rob Biedenharn		http://agileconsultingllc.com
Rob / AgileConsultingLLC.com