Re: extended lua value type question

On Tue, Nov 11, 2014 at 12:59 PM, Tim Hill <drtimhill@gmail.com> wrote:

> On Nov 11, 2014, at 6:33 AM, Chris Cummings <chrisc@mediamolecule.com> wrote:
>
> Hmmm - you know what, after more thought I reckon you guys a right - I reckon I'll have to make vectors reference types, even if I do end up making some modifications to the LUA libraries to make allocating/freeing them faster. Relying on the compiler not to have made (valid) assumptions about the behaviour of settable seems too risky.
>
> Has anyone any experience/examples of adding new types of garbage collectable objects (crucially ones that use their own approach to memory allocation/freeing)?
>
> -Chris
>

If you are going with reference types then why not just use a full userdata? This gives you GC behavior and metatables, which should be enough to allow you to deeply integrate your new type into the system (for example, “a + b” semantics for vectors). All you really need to do is wrap type() so that it can return new strings for your userdata types and they are pretty much first class reference types.

—Tim

I think he's moved on, but it looked like he was trying to solve the problem where:

myvec = vec{x = 1, y=2}

func1(myvec)

func2(myvec)

somewhere inside of func1:

myvec.x = 3

now func2's myvec has changed and he didn't want them to change, outside of func1.

But I don't believe that these semantics can be made to work as he had hoped, without pass-by-value for this object. I can't even think of how you could do that, even if you were to go crazy with it...

-Andrew