I'm working on all the suggestions that you posted on the "output data
structure" subject and I have a question for you all.
Just imagine you are in the middle of a parsing and have just recognized the
body of a K: field.
In ABCp terms, you are in the S_FIELD_K state and got a T_FIELDBODY token
with a string like:
"Am ^f transpose=-2 stafflines=5"
There are four cases:
1) you are NOT intereset in the string (your
application ignore the field);
2) you are ONLY interested in the string (for
example you want to output it as it is);
3) you are ONLY interested in the fine details
of the key field (the tonic, the number of
stafflines, ...);
4) you are interested in BOTH the string and
the details.
The same reasoning may apply to other fields (%%MIDI for example).
To avoid unnecessary work, I decided to provide separate functions to parse
the field bodies instead of parsing them anyway.
In other words, you first receive the entire body of the field as a string
and then, if you are really really interested, you call a function like:
k=abcKey(string);
to really parse the field body, extract all the information and pack them
into k.
And keep in mind that this mechanism have to work even when accessing the
functions from Java, Object Pascal, Lua, Python, ... !
Anyone sees any drawback with this approach?
Remo
the
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
