Re: Feature request: userdata slice

[William Ahern <william@...>]

On Thu, Aug 20, 2015 at 12:19:48AM +0000, 云风 Cloud Wu wrote:
> >
> > This particular use case can be handled in a straightforward way
> > by a method.
> >
> > local t = obj:retrieve(x,y,z)
> >
> 
> I think you mean
> 
> local t = obj:retrieve("x","y","z")
> 
> But how can I do this :
> 
> for k,v in pairs(obj.x) do
>    ...
> end

Like

for k, v in obj:pairs("x","y") do
	...
end

where obj:pairs instantiates an iterator over the keys (if any) of obj.x.y.

Some people have hangups about doing things this way. They feel that if they
can't make it work transparently--using only the most idiomatic Lua
patterns--that it's somehow inelegant.

But the inelegance in this case seems to arise from have 100k Lua VMs, each
directly manipulating shared 10+MB JSON/XML documents, yet utilizing only
the most primitive and tedious of operations. I don't doubt that you have
defensible reasons for the first two conditions. (I'm guilty of building
multi-threaded systems that resorted to manipulating a shared JSON-like data
structure.) But trying to stitch it all together by making it appear as
regular Lua tables seems a little misguided.

I think the key abstraction here isn't Lua tables, but Lua _iterators_. I
would pursue a more declarative-programming solution, in the vein of XPath.