On Wed, 2007-12-05 at 19:38 +0000, Krzysztof Foltman wrote:
Lars Luthman wrote:
Yeah, if it's sorted. I don't really
think it's needed though, iterating
through a couple of hundreds of strings (in extreme cases) isn't that
much work to do at instantiation time.
Well, let's imagine we need to find 50 URIs in the pool of 200. How many
strcmps is that?
Extreme example, I know. But if it's going to be used as generic
URI-to-int translation (not just event type-related), then who knows.
Why decide to use something which has O(M*N) and not O(M*log(N)) (or
even O(M)) average complexity, if the difference in amount of work for
plugin developers is hardly noticable?
Assuming someone provides code to manage the symbol table, the increased
work on plugin authors is 0 (you can still do an ignorant linear search
through sorted array).
Might as well.
I think it would be better if the symbol thing was just a (simple) API
where the implementation is left up to the host (or whatever), rather
than defining some specific data structure to send to the plugin. We
can deal with the details of a really good symbol system later...
-DR-