1 Jun
2006
1 Jun
'06
6:11 p.m.
On Thu, 2006-06-01 at 09:42 +0100, Steve Harris wrote:
On Tue, May 30, 2006 at 03:09:33 -0400, Dave Robillard
wrote:
Hmm.. that's not a bad idea. The current API could remain unaffected
but still allow extension. OTOH, it's not really all that much better
from just returning a string, but I would like to avoid the strcmp and
free thing..
I'm a bit unhappy that it makes code longer
and more messy though. The
primary design goal here is to make host code as terse and simple as
possible. strcmp'ing a string and then freeing it is quite a bit uglier
than just testing an enum val :/
This is maybe a PITA, but what about a runtime provided enum list, like:
foo_enum = { { FOO_FLOAT, LV2_FLOAT_URI },
{ FOO_MIDI, "http://example.org/datatypes/midi" },
{ 0, NULL } };
lv2_set_urilist(foo_enum);
the library can contain an builtin enum list that is set implictly, ie. it
does lv2_set_urilist(lv2_internal_enum); when it starts.
that way simple hosts can just use it as is, and more complex ones can
specify the types they support, and everyone gets to use ints. From an (internal) code standpoint it will definitely
be nicer that a
big if/else chain with the known URIs hardcoded in.
When I do more work on the static 'library state' stuff (eg
lv2_set_urilist, lv2_add_prefix, etc) I'll give it a shot and see how it
works out.
-DR-