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

[Xavier V. <xav...@fr...>]

Hi all !

>  From (briefly) looking at the evaluator, I guess it should also be 
> possible to use more than one character as a delimiter, without things 
> getting _too_ complicated (so, "::" or "->" should be doable). But I 
> don't see the need to do the extra work, which is why I'd vote for "$".
I vote for xmms::filename, it's the same syntax as Perl !
In Perl, to call the function init() provided by module Gtk2, we call
Gtk2::init() or so. Great idea !

BTW:
> So if I understand it all, instead of invoking xmms('filename'), the
> > user should invoke 'filename@xmms', so that the eval knows it need
> > plugin_xmms loaded ? Am I right ?
> No, not really. There are some plugins that offer only one function 
> (like xmms). Here the function name should be the same as the plugin name.
> With Martin's example, the xmms plugin would offer a function 
> 'filename'. You would call this function 'xmms.filename()'. The 
> evaluator could use the portion before the dot to find the plugin.
> That's what I mean with "reverse".
But don't we loose flexibility and extensibility ? A great advantage of
new generation is to have a function which provides tokens independants
from the code ! example: i2c_sensors can provide 'curr_input3' if
there's one an the day a new file 'coffe_machine1' (totally random
example ;) ) appears the plugin will handle it with no change.
Please don't trow this excelent feature !!

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 ??


Bye !
-- 
Xavier VELLO <xav...@fr...>