[MacRuby-devel] floats in core data
johnmacshea at gmail.com
Sat Nov 28 03:12:41 PST 2009
(sorry for the longish post)
I did some simple tests where the bound variable is not actually bound to a CoreData store, but to a method in the custom NSManagedObject class..
(btw - I am not sure if anyone else noticed but a difference between 0.4 and 0.5, is that when binding to custom methods now, the methods have to be mentioned in the valueForUndefinedKey method of the NSManagedObject - before they did not need to be - but maybe in 0.4, this was a lucky time dependency, with the method being loaded before being queried by the view).
- Returning a (ruby) number like 45.3 will not be displayed in the column (with and without formatter) or in fact a plain NSTextField (so it does not seem to be a table cell issue) but returning NSDecimalNumber.decimalNumberWithString("45.3") - will be displayed correctly in both.
- Same issue when binding to a class with only NSObject as the super.
- I also did do some test with the core data stack and KVC/KVO, binding etc and everything worked ok. I now think this issue has nothing to do with CoreData.
- My current suspicion is that the NSTextField is being sent a setObjectValue message which works fine with NSDecimalNumbers - it does not work with MacRuby Floats, or with NSNumbers - although i would expect it to since they are objects.
(bolds added by me for comprehension)
irb(main):005:0> framework "Cocoa"
irb(main):006:0> tf = NSTextField.alloc.init
irb(main):007:0> num = NSNumber.numberWithFloat(23.3)
irb(main):009:0> p tf.stringValue
irb(main):011:0> p tf.stringValue
I will add this to the MacRuby bugs a bit later.
re NSDecimalNumber -> leaving it "untouched" as you said, is, in my opinion the right thing, it would be too confusing for it to have different behavior than what is in the docs.
On Nov 27, 2009, at 9:22 PM, Laurent Sansonetti wrote:
> Hi John,
> This may be a bug in MacRuby, I don't know bindings well enough. It would be cool if you could reduce the problem into a small Ruby script.
> We are indeed unboxing NSNumbers automatically. NSDecimalNumber seems to be left untouched, which could explain why the normal arithmetic operators do not work.
> On Nov 27, 2009, at 7:50 AM, John Shea wrote:
>> Hi all,
>> does any one know whether there is an issue with binding to floats, doubles in core data with macruby?
>> For example:
>> 1 I firstly, create an attribute foo which is set as a double or a float in the core data model
>> 2. i bind it to a table column
>> 3. I set foo to 300.3 in code (not through the user interface)
>> 4. it comes through as 1 (or 1.00 if formatted - which is probably neither here nor there)
>> If i do the same but set the attribute to be of type decimal - then the number 300.3 comes through fine.
>> The problem then is that is that the class of foo is NSDecimalNumber - and its really painful doing calculations with NSDecimalNumbers given that normal arithmetic operators do not work.
>> I haven't found it to be that accurate either (at least in Objective C) - compared to ruby floats.
>> The strange thing is that both end up (in macruby) inheriting from NSNumber - but somehow the binding cannot make sense of it.
>> Is it possible that there is a non macruby translation going on? - an unboxing - because the binding/kvc access thinks that foo is a float? (which it might be, in the persistent store - but does not seem to be by the time its accessed).
>> I can think of work arounds - but i thought i better check with the experts first ;-).
>> MacRuby-devel mailing list
>> MacRuby-devel at lists.macosforge.org
> MacRuby-devel mailing list
> MacRuby-devel at lists.macosforge.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the MacRuby-devel