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