Re: Adding custom bulit-in type

[John W <jwdevel@...>]

>From Roger/bil:
> I have attached an example of transparently wrapping the "glm" library
> ... nice example about "Bit arrays" in Roberto's book

Yes, I currently already have "vec2" implemented as a userdata type —
based on GLM too, as it happens (though I am using kaguya rather than
sol for bindings). And I do enjoy the book (:

I'm interested in this path primarily as an optimization, to remove
userdata allocations and indirections, since I use a lot of these objects.

Regarding Luiz/Sean/Roberto's line of discussion:

>>   What am I missing?
> Whatever you do, __newindex receives a copy of the original 'v', not
the original.

In that example Sean gave, it is 'self' being modified, not 'v'.
i.e. "foo.x = 3", would mean v==3, no?  But I guess the same logic
applies to 'self'?

If there is no way, even in C, to "get to the underlying TValue*" like
Sean mentioned, I guess the best alternative would be to have an
immutable-style API, like:

  v = vec2(0,0)
  v = v:withX(123) -- now v == vec2(123, 0)

  -- alternatively:
  v = vec2(123, v.y)

where any time I want a "mutating" function, I'd instead have one that
returns a new copy, similar to above.

It's not my ideal syntax, but maybe good enough.

Could this version work?


On 7/27/23, Sean Conner <sean@conman.org> wrote:
> It was thus said that the Great Roberto Ierusalimschy once stated:
>> > 	  __newindex = function(self,k,v)
>> > 	    if k == 'x' then
>> > 	      -- magic  code to set x portion of self to v
>> > 	    elseif k == 'y' then
>> > 	      -- magic code to set y portion of self to v
>> > 	    end
>> > 	  end
>> > 	}
>> > 	
>> >   What am I missing?
>>
>> Whatever you do, __newindex receives a copy of the original 'v', not
>> the original. If 'v' is/has a pointer (created with allocation), then
>> the copy and the original point to the same memory, and changing that
>> memory affects both 'v' and the original value. If 'v' does not
>> is/has a pointer, then changing it cannot affect the original value
>> that 'v' is a copy.
>
>   I take it there's no easy way to get to the underlying TValue *?
>
>   -spc
>