* Datastructure for table
@ 2010-01-14 22:00 Johan Andersson
0 siblings, 0 replies; 3+ messages in thread
From: Johan Andersson @ 2010-01-14 22:00 UTC (permalink / raw
To: help-gnu-emacs
[-- Attachment #1: Type: text/plain, Size: 624 bytes --]
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.
Thanks!
[-- Attachment #2: Type: text/html, Size: 687 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Datastructure for table
[not found] <mailman.1435.1263510168.18930.help-gnu-emacs@gnu.org>
@ 2010-01-15 0:23 ` Tim X
2010-01-15 16:45 ` Johan Andersson
0 siblings, 1 reply; 3+ messages in thread
From: Tim X @ 2010-01-15 0:23 UTC (permalink / raw
To: help-gnu-emacs
Johan Andersson <johan.rejeep@gmail.com> 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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Datastructure for table
2010-01-15 0:23 ` Datastructure for table Tim X
@ 2010-01-15 16:45 ` Johan Andersson
0 siblings, 0 replies; 3+ messages in thread
From: Johan Andersson @ 2010-01-15 16:45 UTC (permalink / raw
To: Tim X; +Cc: help-gnu-emacs
[-- Attachment #1: Type: text/plain, Size: 2171 bytes --]
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 <timx@nospam.dev.null> wrote:
> Johan Andersson <johan.rejeep@gmail.com> 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
>
[-- Attachment #2: Type: text/html, Size: 2755 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2010-01-15 16:45 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <mailman.1435.1263510168.18930.help-gnu-emacs@gnu.org>
2010-01-15 0:23 ` Datastructure for table Tim X
2010-01-15 16:45 ` Johan Andersson
2010-01-14 22:00 Johan Andersson
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.