Re: [Lcd4linux-devel] Re: Dynamic loading (once more ;)

[Michael R. <re...@eu...>]

Hi guys,


Here's my vote: I vote for '_'

why?

- there is no real 'object/method' system behind, so why try to mimic one?

- the only reason for this delimiter is that the evaluator needs a hint 
how to find the plugin that offers a specific function. So the function 
name has to start with the plugin name. If a plugin offers just one 
function, it may take only the plugin name (without any extension)

- integrating into the parser is not that easy with other delimiters. Te 
parser reads "tokens", and one possible token is a NAME, which consists 
only of alphanumeric chars and the _. The trick is that variable names 
and functions can be parsed the same way (and have the same token), if 
the next char is an opening brace, it's a function, if not, its a variable.

When using any of the chars you suggested, I have rewrite the parser, 
and take the following into account:

- double occurence of the delimiter
- delimiter at the beginning or the end
- delimiter in variable names

>> Maybe a plugin could register multiple namespaces, but how would the
>> eval know them ? We fall in the same problem :/
>>
>> Another solution would have to have : - xmms::parse('token')
>> - i2c_sensors::parse('token')
>> - proc_stat::parse('token')
>> - proc_stat::disk('token')
>> - proc_stat::cpu('token', 'delay')
>> - ...
>> So a plugin may have multiple functions, and one-function plugins
>> register only a generic parse() function. What about it ??
> 
> Well, after checking the existing code of the plugins (and lots of 
> editing this email...), that would sound like a very good idea to me, if 
> we can get rid of the (somewhat redundant) "parse". Maybe something like 
> a "default function", if only the name of a plugin is supplied?

I'm sorry, but I don't understand this discussion.

 From the evaluator's point of view, he knows nothing about tokens and 
parsers and stuff. It behaves simple:

function call to foo():
    if foo is registered, call it
    else try to load a modules called 'plugin_foo.so'
    if registered now, call it
    else remember the failure and output an error (so on the
    next try it won't try loading again)


function call to foo_bar():
    if foo_bar is registered, call it
    else try to load a modules called 'plugin_foo.so'
    ...


from the plugin's point of view, it's absolutely free to you (the 
author) wether to implement a "generic parsing function" with the 
requested item as a parameter, or to implement a seperate function for 
each item, or both.

Both ways may make sense: there are sources where you cannot know which 
items may occur: netdev() for example: how should I know how much 
network interfaces are there, and how thy're called today?


bye, Michael

-- 
Michael Reinelt                                   Tel: +43 676 3079941
Geisslergasse 4                                   Fax: +43 316  692343
A-8045 Graz, Austria                          e-mail: re...@eu...