[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Ideas about colon operator syntax (and a patch in the work)
- From: "Thomas Jericke" <tjericke@...>
- Date: Fri, 02 May 2014 17:41:52 +0200
-----Original Message-----
> From: "Dirk Laurie" <dirk.laurie@gmail.com>
> To: "Lua mailing list" <lua-l@lists.lua.org>
> Date: 02-05-2014 12:02
> Subject: Re: Re[2]: Ideas about colon operator syntax (and a patch in the work)
>
> 2014-05-02 10:49 GMT+02:00 Thomas Jericke <tjericke@indel.ch>:
>
> > Now I can't use the colon operator as 'obj.cmd:funct(1)' would be 'obj.cmd.funct(cmd, 1)' but I
> > want obj.cmd.funct(obj, 1). Anyway my solution was simple, obj.cmd.funct is a userdata that has a __call in
> > its metatable that does the call, and it has all the information stored in the userdata that it needs.
>
> Lua functions are anonymous: you can assign them to names
> but the function does not know what its name is. The debug
> library can make an educated guess which is often right, some
> local variable can say what the function thinks its own name is,
> but by the time `funct` is called, it does not know whether
> it was associated with `obj.cmd.funct` or with `local f` or whatever.
I am not interested in the name of the function. I don't know
how you got the idea that this is relevant. The debug library is not involved at all.
>
> Nothing forces you to call a function that was declared with colon
> syntax only as a method; you can always call it plainly with an
> explicit first argument.
>
> So to get `funct` to know what `obj` is, the value `obj` is in some sense
> an upvalue for `funct`. There are probably all sorts of clever tricks
> involving the debug library, but I prefer an explicit `parent` field
> in this sort of situation.
Again if obj is an upvalue of funct, you don't need to use the
debug library at all. You just use the upvalue:
function CreateObject ()
local obj = {}
function obj.cmd.funct(...)
dosomethingwith(obj)
end
return obj
end
Anyway this in not the way I used, in our framework funct
is a userdata that store a struct with a pointer to the
C++ object and the function.
>
> > obj = {}; obj.cmd = {parent = obj}
> > function obj.cmd:funct(...)
> local parent = self.parent
> if parent and parent.cmd == self then self = parent end
> return self,...
> end
> > return obj.cmd:funct(1,2,3)
> table: 0xe137f0 1 2 3
> > return obj
> table: 0xe137f0
That is possible, but it is not what our script programmers were used to
before we moved to Lua.
We have statements like:
Module.Portal.Cmd.MoveXY(12, 24)
Module.Head.Cmd.Pick()
Module.Portal.Cmd.MoveXY(5, 22)
Module.Head.Cmd.Place()
...
over and over again and often the shortcut:
local MovePortal = Module.Portal.Cmd.MoveXY
MovePortal (12, 24)
is used to call MovePortal without any table lookups involved.
I am actually very satisfied with this solution,
and of course I can't change that anymore now without braking all
the scripts already written like this.
--
Thomas
- References:
- Re: Ideas about colon operator syntax (and a patch in the work), Michael Richter
- Re: Ideas about colon operator syntax (and a patch in the work), Thomas Jericke
- Re: Ideas about colon operator syntax (and a patch in the work), Dirk Laurie
- Re: Ideas about colon operator syntax (and a patch in the work), steve donovan
- Re: Ideas about colon operator syntax (and a patch in the work), Thomas Jericke
- Re: Ideas about colon operator syntax (and a patch in the work), steve donovan
- Re: Ideas about colon operator syntax (and a patch in the work), Thomas Jericke
- Re: Ideas about colon operator syntax (and a patch in the work), Dirk Laurie
- Re[2]: Ideas about colon operator syntax (and a patch in the work), Thomas Jericke
- Re: Re[2]: Ideas about colon operator syntax (and a patch in the work), Dirk Laurie