[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [proposal] infix function syntax sugar
- From: Philipp Janda <siffiejoe@...>
- Date: Tue, 20 Dec 2011 13:51:36 +0100
On 20.12.2011 11:34, Xavier Wang wrote:
> 在 2011-12-18 傍晚6:32，"Philipp Janda"<firstname.lastname@example.org>写道：
>> (although I still can't see how infix
>> functions would help him solve his userdata allocation problem):
> Sorry for late reply, I'm just fired by boss :-( so I can't online serveral
Sorry to hear that.
> think this:
> local f = obj:getflags()
> if f:contains "FOO, BAR" then
> -- do something
> if you want to write f:something, then f must a userdata or table, so you
> must allocate a memory for that value.
As far as I know, f can be anything including numbers, lightuserdata and
strings. With some C hacking you could probably even use boolean (which
is an int in the C implementation).
> but if you do conditions like this:
> if contains(f, "FOO, BAR") then
> -- do something
> then no memory will allocate. but it's not clearly, think this:
> if f `contains` "Foo, Bar" then
> it just a syntax sugar of normal form. it's very like f:contains, but don't
> need allocate any memory.
That depends on what f is. If you want type-safety, f is a table or a
full userdata and you need to allocate memory. If you don't need
type-safety (i.e. if you are the only one using lightuserdata), and you
are ok with implementation-defined behavior, you would probably use
lightuserdata. Else you have only numbers.
To implement type-safe enums, I would add something like
to the Value union in lobject.h and a global counter (in the registry,
maybe) to create unique enum_ids. This wouldn't bloat Lua objects for
the common case that lua_Number is a double, and you would have lots of
different type-safe enum types of 32 Bits each. You could even
reimplement booleans as a special case of one of those enum types.
There was an enum patch some time ago, but I think it allocated extra
memory for the enums.