Have NSNumber keep a copy of its source String

[GoogleCodeExporter]

Have NSNumber keep a copy of its source String

[GoogleCodeExporter]

I would rather fix the toString() method, so that it does not add a decimal dot 
to integers. I will implement that behavior that when I have time. That should 
solve the problem you have.

Original comment by daniel.dreibrodt on 19 Sep 2014 at 3:29

• Changed state: Accepted
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

That won't work for NextStep plists, because the code tries to store gigantic 
numbers like 100000000000002900000044 as Doubles. This seems to be rooted in 
the problem that numbers and strings look the same in NextStep plists, and the 
code tries to autodetect which type you want, which isn't really possible.

In your solution, what happens if I want to store a string "10.0"? I believe 
the autodetection logic will think it is a double, store it as a 10.0, and the 
toString method will remove the ".0".

Original comment by [email protected] on 19 Sep 2014 at 5:07

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

I realized I neglected to mention that these numbers are just too big to store 
as Doubles, so the auto-detection logic loses data.

Original comment by [email protected] on 19 Sep 2014 at 5:09

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

After reexamining the few documents still available about ASCII property lists 
I came to the conclusion that I should remove the part from the parser that 
attempts to parse numerical strings as numbers. In GnuStep there is an explicit 
syntax for storing NSNumbers (<*I1234> or <*R12.34>) but other formats handle 
numbers as strings. So for conformity with the existing systems the automatic 
conversion of numeric strings into NSNumbers will be removed. Then such 
property lists as the ones you are working with should work fine. If a user 
wants to have a number from a string he can do the conversion himself, because 
is a rather trivial task. What would you say?

Original comment by daniel.dreibrodt on 22 Sep 2014 at 9:14

• Added labels: Type-Defect
• Removed labels: Type-Enhancement

[GoogleCodeExporter]

Yes, that seems much cleaner, and I'm happy with doing conversion explicitly. I 
didn't realize there was a special syntax for NSNumbers, since I've been using 
dd_plist almost exclusively on xcodeproj files, which I don't believe ever use 
that syntax.

Thanks,
Matt

Original comment by [email protected] on 23 Sep 2014 at 4:19

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Should be fixed in r111

Original comment by daniel.dreibrodt on 23 Sep 2014 at 6:23

• Changed state: Fixed
• Added labels: ****
• Removed labels: ****