Re: C# LuaInterface casting

[Asko Kauppi <askok@...>]

I'm interested to see, what kind of response you will get...

To me, it seems LuaInterface is the reason here, but I may be dead  
wrong.  If you do binding 'manually', your binding function can  
return multiple types to Lua, depending on what kind of object  
actually was received by the binder. Perhaps, LuaInterface is making  
a simplification here, which sort-of ties your ankles?

As said, I may be wrong. :)

-asko


Dan Hubbert kirjoitti 4.8.2006 kello 11.31:

> Hi list,
>
> I realise that asking a casting question in a dynamically typed  
> language is odd, but I'm hoping this will make sense.
>
> I'm using Lua 5.1, .Net 2.0 and the LuaInterface to build a tool to  
> automate actions in Microsoft Content Management Server 2002 using  
> Lua scripts. Mostly the Lua scripts will call utility functions  
> I've written in C#, but occasionally it would be easier to call a  
> native function from the Lua script, and this is where I get  
> casting problems.
>
> For example MCMS publishing API provides a function 'GetByPath'  
> that returns a HierarchyItem if you provide the Path of an MCMS  
> object. HierarchyItem is the base class for many more specific  
> classes like Posting, Channel etc and the function could return any  
> of those more speficic types.
>
> There are many functions which require a Posting or Channel as a  
> parameter though. If you call GetByPath from Lua the HierarchyItem  
> gets turned into a UserData object, and when you pass it back to C#  
> it will be a HierarchyItem again. Is there any way to change that?  
> Can you cast a parameter before it gets turned into a UserData  
> object, so that it is a more specific type when it gets passed back  
> to C#?
>
> I've written various C# wrapper functions at the moment which do  
> the casting for me, but I'd like to distribute this tool to our  
> systems team and have them only editing scripts. If these wrapper  
> functions are really necessary I can see them having to make more  
> and uses for these scripts evolve.
>
> Thanks,
>
> Dan Hubbert