Re: Newby questions #2: ffi.load, ffi.metatype, ffi.C

  • From: QuentinC <webmaster@xxxxxxxxxxxx>
  • To: luajit@xxxxxxxxxxxxx
  • Date: Sun, 01 Jul 2012 15:41:26 +0200

> On Windows every DLL has its own namespace. To resolve a symbol in
a DLL, you have to explictly load the DLL. Everything else is an
illusion the compiler or the FFI creates for you.

OK, thank you.

> That's a matter of taste. I think it may introduce more confusion
in the long term. E.g. you'll often want to look up a function
name used on the Lua side in a manual written for the C side,
which shows the C function names of course.

It depends on what you want. If you are thinking for lua users, it may be useful. The primary goal I see from that function renaming is get rid of redondant prefixes. For exemple if you load a library called mylib, there is a chance that the functions you are importing have a 'mylib_' prefix (that's a well known C convention). When you use mylib = ffi.load, then you get mylib.mylib_xxx to call a function. The function prefix becomes useless and even illogical if you think the ting for your users who knows how to program in lua but not necessarily in C.

> [It's a bit complicated to explain the rationale behind this.
Summary: a foo.method lookup would require creating a short-lived
bound-method object which is kind of expensive (cf. Python). Also,
implicit method binding may cause confusion about the bound object
in some contexts (cf. Javascript).]

OK. I'll make a search about that object binding problem.

> You can simply call foo() to construct an object. If you're not
happy with the default constructor, then override __new (only in
LuaJIT git HEAD).

OK, I'll wait for luajit then.

Thank you very much for your answers.

Other related posts: