I will try to think from the "use perspective" as you say and figure out which of them that works best. Thanks! On Fri, Jan 15, 2010 at 12:23 AM, Tim X wrote: > Johan Andersson writes: > > > Hey, > > > > I have an Org-table looking like this: > > | person | car | wife | > > | John | Volvo | Susan | > > | Peter | BMW | Greta | > > | Stefan | Golf | Althea | > > > > I want to parse this so that I get one object per row (execpt the > > header, which defines the keys). So if I for example have the first > > object, I want to be able to fetch the value of some column given the > > header key. The table is dynamic and can have any number of columns > > and the header names differ. > > > > What kind of datastructure would fit for this? I can think of a few > > that may work (Hash-table, Struct and Plist), but none that fit very > > well. > > > > Well, its difficult to say what structure would work best because this > really depends on what you plan to do with the data and the relative > frequencies of the various operations you will be performing. > > Additional options you didn't mention could include > > 1 Association lists. Keys would be columns. Has the advantage > of being able to use assoc etc to get/set values > 2 Nested lists. First sublist could be the list of column > names. Subsequent lists could be each record. > 4. Objects i.e. EIEIO (Enhanced Implementation of Emacs > Interpreted Objects) > > Assuming the tables will vary re: columns and column names and assuming > as these are org based tables, there not going to be that large, I would > be tempted to go with alist or nested lists. However, it really depends > on what you plan to do with the data. If your not going to be updating > the values much, nested lists could be pretty easy to implement. > However, if you need access to specific column values, alist may be > better. > > Choose the structure that makes the most frequent or most complex > operations easiest to code and maintain. > > Tim > > > > -- > tcross (at) rapttech dot com dot au >