StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p><strong>Important Edit</strong>: OK, I'm stupid (and looking for complex answers to simple questions). A quick read of the Wax blog and I find <a href="https://github.com/probablycorey/wax/wiki/Overview" rel="nofollow">https://github.com/probablycorey/wax/wiki/Overview</a>, which mentions the <code>toobjc</code> function. As such, it looks a like like...</p> <pre><code>local x = (toobjc)(NDecimalNumber:initWithString("2.3")); </code></pre> <p>will do what you want (i.e. prevent automatic Lua type conversion). I may have the syntax slightly wrong, so experiment. I've left my original answer below to illustrate another "solution".</p> <hr> <p>So, looking over Wax (which I'm not intimately familiar with), one key act it performs when bridging Objective C and Lua is to convert all Objective C types it can into suitable native Lua types. This includes <code>NSNumber</code> types (such as <code>NSDecimal</code>) which are mapped to Lua number types.</p> <p>Of course, you already know this, hence your changes to <code>wax-helpers.m</code>. Alas, what you've done isn't quite enough - conversions are still happening, and hence your <code>NSDecimalNumber</code> still becomes a number. It seems that, depending on whether this gets used in your Lua code, either Lua blows up (trying to index a scalar type), or the Objective C bridge blows up. I'm not sure why you only get the Lua trace error <em>sometimes</em> (assuming your code is always identical); it points to some underlying assumptions about the internal Wax state being violated.</p> <p>The best solution will be one that doesn't involve changing Wax. At the moment, even if the "fix" did work, you've totally disabled the automated coercion between types. This will, I assume, break quite a lot of Wax code and idioms. Looking at Wax, it will only perform automated conversions for types that subclass certain Foundation classes it specifically understands; any object type that it doesn't know about remains an object. In this case, we're caught in the <code>NSValue</code> and <code>NSNumber</code> conversion, so my first suggestion is to simply wrap <code>NSDecimalNumber</code> in some class that Wax doesn't understand. Something like...</p> <pre><code>@interface MyDecimalWrapper : NSObject { NSDecimalValue *myDecimal; } - (NSDecimalValue*)getDecimalValue; - (NSDecimal*)getDecimal; @end @implementation MyDecimalWrapper - (NSDecimalValue*)getDecimalValue { return [[myDecimal retain] autorelease] } - (NSDecimal*)getDecimal { return [myDecimal decimalValue]; } @end </code></pre> <p>This can be added to Wax without changing it's code significantly, and using this to carry a <code>NSDecimalValue</code> across the bridge should prevent Wax's type conversion. Of course, if you use <code>getDecimalValue</code> inside Lua, the result will promptly be wrapped into a Lua <code>number</code>. If you need to call methods on the underlying <code>NSDecimalValue</code> in Lua, just proxy them from equivalent methods defined on the wrapper.</p> <p>If this absolutely doesn't work for you, I can probably work out the changes needed to Wax. But it <em>will</em> be a world of hurt maintaining your own port, and breaking lots of existing Wax code and examples.</p> <p>Tangentially: I'm not sure what you intend to do with an <code>NSDecimal</code> once you've got one in Lua. It's an opaque C structure, that can only be used through a C interface provided by Foundation.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload