userdata considerations

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

userdata considerations

mnicolet
I migrated to lua 5.0a because userdata manageability.
Also, I devised a lot of userdata support routines.
They are included in luapi ... I will post the lua 5.0 version
of it next days.
The best (unique ?) way I found to deal with userdata is
to have a ´constructor´ for every of them;
u = newudtype( construction arguments here )
Of course, every userdata ´type´ must have its own constructor, and of
course, the constructor semantics
is privative for the ´type´ ...
But I´am thinking about lua´s native support for that
stuff.
My first and main ´userdata´ is a lua bind to some class
I use extensively in my applications to ´wrap´ the native
C/C++ objects. So, a ´userdata´ of this type is in fact
pointing to what is, actually, a C string or integer or
double, etc. Also, as an extension, I use this wrapper
class to define date and time ´objects´ of my own.
Then, to construct an object of this kind from lua code,
one could write
u = myuserdata( "text" )
v = myuserdata( 5.5 )
w = myuserdata( "2002-10-11" )
This works fine
After that, what follows seems to be natural
if u == "text" then ....
if v < 6 then ...
But the ´native´ VM will refuse to apply the logical operators because of
different types. The ´correct way´
to do this is
if u == myuserdata( "text" ) then ...
if v < myuserdata( 6.0 ) then ... ( this works ok )
which is a lot more verbose and, worse, is a memory
and time waste.
It seems to me that regarding userdata, some C++ concepts should apply: one
could extend the language
semantic when the types involved are user types.
Also, it´s easy to ´hack´ the VM code so
the relational functions ( lessthan and equalthan ) first check to see if
some of the args is a userdata with the
corresponding ´tm´, and being the case, simply pass the
args to the ´tm´.
Same considerations apply to arithmetic operators.
But another question arises with asignation. Supose you
have:
u = myuserdata( 6 )
v = myuserdata( 8 )
u = v
now, ´u´ is binded to the thing which ´v´ points to.
It´s ok for the native lua ´types´ ... and also for userdata
is they were defined as script variables ( like the example ).
But suppose that ´u´  is a global variable ´pointing´ to some host object
and ´published´ by it, to interchange
information with the script without resorting to function
calls ( yes, I know that is not the better way, but sometimes the best way
is the more simple and slim ).
In this case, the host global would be pointing to a script
object ( which may be garbage collected also ) ...
The intended effect was that the C object to which ´u´
points, gets the value of ´v´ ( 8 in the example ).
Clearly, what is needed is that assignation to userdata
can follow the same path of other operations: being the
left member a userdata and having a ´tm´ for assignation,
call that tm with the rigth expression result.
Here are the my big questions:
a) I cannot find which is the opcode for assignation
b) Worse: I cannot figure exactly how to add a new
´tag method´ to the metatables. More exactly, where and how to find all
consequences of such an addtion.
c) This a major ´hacking´ involving various source modules, and so,
difficulting every further version adoption.
( Note that the changes to relational and arith operator
are confined to VM module ).
I would like to hear from lua authors regarding this issue.

Except for the above considerations, I find the userdata
support in lua 5.0a very easy and powerful. In fact, any
userdata can have all the ´methods´ you like.
Is this easyness to define methods an indication that
what I am trying is the wrong way ? See

if u:Str( ) == "text" then ...

if u:Lt( 6 ) then ...

u:assign( v )

regards
Marcelo


Reply | Threaded
Open this post in threaded view
|

userdata considerations

Basile STARYNKEVITCH
>>>>> "mnicolet" == mnicolet  <[hidden email]> writes:

    mnicolet> I migrated to lua 5.0a because userdata manageability.
    mnicolet> Also, I devised a lot of userdata support routines.
    mnicolet> They are included in luapi ... I will post the lua 5.0
    mnicolet> version of it next days.  The best (unique ?) way I
    mnicolet> found to deal with userdata is to have a "constructor"
    mnicolet> for every of them; u = newudtype( construction arguments
    mnicolet> here ) Of course, every userdata "type" must have its
    mnicolet> own constructor, and of course, the constructor
    mnicolet> semantics is privative for the "type" ...  But I"am
    mnicolet> thinking about lua"s native support for that stuff.  My
    mnicolet> first and main "userdata" is a lua bind to some class I
    mnicolet> use extensively in my applications to "wrap" the native
    mnicolet> C/C++ objects. [...] 

I skipped an interesting part of Mnicolet's message. But I think it
raise the following issue: is lua a C or C++ embeddable scripting
language, i.e. does the Lua API target C or C++?

I definitely think Lua (even the 5. and future 6. versions) should
target C, not C++.

If you designed a language easy to embed into C++ applications (which
lua is not, it targets C not C++) you'll get a different API and a
different language.

I undestand C++ coders are using Lua, but Lua should target C coders,
not C++ one!

-- 

Basile STARYNKEVITCH         http://starynkevitch.net/Basile/ 
email: basile<at>starynkevitch<dot>net 
alias: basile<at>tunes<dot>org 
8, rue de la Faïencerie, 92340 Bourg La Reine, France

Reply | Threaded
Open this post in threaded view
|

Re: userdata considerations

mnicolet
The question I posted is not strictly related to which language ( C or C++ )
should lua target. In fact, I think
it´s better to have a C interface and ´conception´ ... it´s
more ´useable´ than to jacket all people and circumstances to C++. At last,
it´s allways possible to
interface C++ to C, the opposite is not always straigthforward. The
´constructor´ I mentioned for userdata is a matter of convenience, and has
no intimate
relation to the host language itself ( my tests are writen and compiled
using plain C ). In fact, a userdata ´method´
may or may not correlate with a C++ ´method´. Also, the
wiki has a beatyful example of how to interface a C++ class to a lua
userdata ( I learned a lot of it ).
What I am taking from C++ is the basic concept behind
´user types´ not being second class citizens. So, C++ allows one to
´redefine´ ( or plainly, define ) what the
asignation, comparation, and arith ops means to a class.
Also, it allows the programer to define the semantics of
user-class-to-native-objects operations, etc
It´s not necessary to change the lua interface ( or language ) to get these
OO ideas supported
----- Original Message -----
From: "Basile STARYNKEVITCH" <[hidden email]>
To: "Multiple recipients of list" <[hidden email]>
Sent: Tuesday, October 08, 2002 2:35 PM
Subject: userdata considerations


>>>>> "mnicolet" == mnicolet  <[hidden email]> writes:

    mnicolet> I migrated to lua 5.0a because userdata manageability.
    mnicolet> Also, I devised a lot of userdata support routines.
    mnicolet> They are included in luapi ... I will post the lua 5.0
    mnicolet> version of it next days.  The best (unique ?) way I
    mnicolet> found to deal with userdata is to have a "constructor"
    mnicolet> for every of them; u = newudtype( construction arguments
    mnicolet> here ) Of course, every userdata "type" must have its
    mnicolet> own constructor, and of course, the constructor
    mnicolet> semantics is privative for the "type" ...  But I"am
    mnicolet> thinking about lua"s native support for that stuff.  My
    mnicolet> first and main "userdata" is a lua bind to some class I
    mnicolet> use extensively in my applications to "wrap" the native
    mnicolet> C/C++ objects. [...]

I skipped an interesting part of Mnicolet's message. But I think it
raise the following issue: is lua a C or C++ embeddable scripting
language, i.e. does the Lua API target C or C++?

I definitely think Lua (even the 5. and future 6. versions) should
target C, not C++.

If you designed a language easy to embed into C++ applications (which
lua is not, it targets C not C++) you'll get a different API and a
different language.

I undestand C++ coders are using Lua, but Lua should target C coders,
not C++ one!

--

Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net
alias: basile<at>tunes<dot>org
8, rue de la Faïencerie, 92340 Bourg La Reine, France