Re: [ANN] Lua Alchemy 0.2

[Alexander Gladysh <agladysh@...>]

>> We, Lua Alchemy development team, just released new version: 0.2.

>>        http://code.google.com/p/lua-alchemy/

> Thank you! This is a very exciting project.

You're welcome! I'm glad there is an interest in Lua community for Lua Alchemy.

>> Main feature of this release is syntax sugar. If in 0.1 you had to write
>>
>>        as3.call(myvar, "someCall", param1, param2)
>>
>> Now you may make calls naturally:
>>
>>        myvar.someCall(param1, param2)
>
> Now, this is an interesting thing - when you say "naturally", I guess you
> mean "naturally for an ActionScript 3 object", but of course the way you
> (usually) call a method on a Lua object is to use the colon rather than a
> dot.

Well, anyway, "more naturally" then the original method.

> It's fine if the object is one that is only ever going to be used by
> Lua code that knows what it's dealing with is an as3 object, but in more
> complex uses of Lua Alchemy I can see situations where you want to call
> methods on an object without knowing whether it was implemented in Lua or
> ActionScript.

There is at least one native Lua way to implement objects where calls
are to be done with dot notation (one that uses upvalues). I agree
this method is not the most popular one (I use it rarely myself). I
agree dot notation may be a usability problem in Lua Alchemy API.

> What do other people think? Is it worth having a redundant first parameter
> for compatibility with Lua objects in these situations, or preferable to use
> "object.method" instead of "object:method" if it's actually internally more
> natural to do so?

We (Lua Alchemy developers) are interested in other people opinion as
well. Please share.

It is more natural for the implementation to not have redundant "self"
parameter. Furthermore, I think, with *current* implementation there
would be a noticeable performance hit if we allow colon notation:

    foo.bar()

means internally

    as3.call(foo, "bar")

But

    foo:bar()

means

    as3.get(foo, "bar") -- creating an AS3 closure -- and throwing it away
    as3.call(foo, "bar")

There *could* be some ways to alleviate this though... Again, if this
issue bothers anyone, please share your opinion. :-)

Alexander.