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

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

Hi there,

>>>If you want to make it look like OOP, you can use "." for a delimiter=20
>>>(but it may screw up the parser, since "." is already used for string=20
>>>concatenation).

> we could use @, it seems to be very fashion ;) Moreover, it represents
>  well the 'namespace' concept.

I don't like it, because I'd reverse the 'object' and the 'method'.

> 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=20
(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=20
'filename'. You would call this function 'xmms.filename()'. The=20
evaluator could use the portion before the dot to find the plugin.

That's what I mean with "reverse".

xmms@filename looks

 >
 > But then, how would the plugin handle this ?
 > Eval my call the function xmms('filename'), but this may lead to
 > problems with plugin_proc_stat :/
 >
 >
 >>It gives us the same results as the "global function to plugin mapping=
",
 >>but easier to implement (no compile-time work necessary), and allows f=
or
 >>modules to be used without recompiling all the stuff. It does not
 >>require a list of modules to be specified in the config file.
 >
 > Right, it may be a good solution.
 >
 > About dynamic loading of plugins, Martin wrote :
 >
 >>But I'm looking at embedded systems (well, not _quite_ embedded, but a=
t
 >>least very limited as far as space goes), where building can be a pain=
,
 >>and always needs to be done on a separate system. So what I like to do
 >>is do a "build everything" on my devel box, and then just transfer the
 >>plugins/drivers I need on a specific installation. If a new module
 >>arrives in the source tree later on (and I need none of the new
 >>functionality of lcd4linux), I could simply pop in the new plugin on t=
he
 >>embedded box, and be done with it.
 >
 > I think you would have to pop lcd4linux binary too, or 'unresolved
 > symbols' may appear (think of hashes, cfg, ... which are evolving quit=
e
 > rapidly). But, it's right, in this case my fixed-compiletime hash isn'=
t
 > a good choice.
 >
 > Bye !
ugly.
xmms.filename look cool, but will not work.

so lets try all the delimiters I can find:

xmms^filename: NO (power 3^2)
xmms=B0filename: NO (not standard ASCII)
xmms!filename: NO (logical NOT)
xmms"filename: NO (uncool)
xmms=A7filename: maybe
xmms$filename: maybe
xmms%filename: NO (modulo)
xmms&filename: maybe
xmms/filename: NO (division)
xmms(filename: NO
xmms)filename: NO
xmms=3Dfilename: NO (equality, assignment)
xmms?filename: NO (implicit if)
xmms`filename: NO (string delimiter)
xmms?filename: NO (dangerous becaue looks like `)
xmms+filename: NO (addition)
xmms*filename: NO (multiplication)
xmms~filename: NO (bitwise not)
xmms#filename: NO (comment)
xmms<filename: NO (less than)
xmms>filename: NO (greater than)
xmms|filename: NO (logical OR)
xmms,filename: NO (expression list)
xmms;filename: maybe, but uncool
xmms.filename: NO (string concatenation)
xmms:filename: NO (implicit if)
xmms_filename: NO (normal char)
xmms-filename: NO (subtraction)
xmms@filename: maybe, but uncool

Did I forget something?

Votes are welcome!

another possibility would be to use another char for string=20
concatenation (but which one? I used the dot because Perl does so)


bye, Michael

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