On Apr 15, 2010, at 12:14 PM, Murat Konar wrote:
> On Apr 14, 2010, at 8:21 PM, Bill Hernandez wrote:
>
>> The point is that NSNumberFormatter appears to me missing some flexibility
>> in dealing with other than its own set of formatting converters, whatever
>> the programmers thought they would need at the time they wrote it.
>
> Well, yes, but I think we have an expectation mis-match problem. The
> programmers had in mind a much smaller problem than the one you wish they did.
>
> Perhpas NSNumberFormatter could have been better named
> (NSQuantityFormatter?), but I don't think NSNumberFormatter was ever
> concieved of as being a one-stop solution for all numeric(ish) formatting.
> There is no way to make a class perfectly general and suitable for all ways
> of formatting arbitrary inputs.
>
> So you specialize based on what the input represents. For example, there is
> another subclass of NSFormatter called NSDateFormatter which is specialized
> to convert date objects to more friendly presentation strings. Obviously,
> knowing that an input represents a date makes parsing it quite a bit simpler.
> I wrote my own MIDI message formatter which takes MIDI messages, which are
> represented as a sequence numbers, and presents them as either binary or
> hexadecimal bytes. Again, the knowledge that the input is a MIDI message
> makes converting it a lot easier.
Murat,
Funny, how you and I have come to some similar ideas...
During the night I was thinking that with the limitations placed on
NSNumberFormatter, compared to other num2string formatters I have used over
time, it should have probably been called NSCurrencyDisplayFormatter, or
something more limited than what NSNumberFormatter implies.
Floating point vars know nothing about dollar signs, commas, etc. They are
stored as a float internally, but are displayed in an NSTextField , or provided
to a string, with either no string formatting as "43.75", or with some display
formatting such as "$ 43.75". The point is that NSNumberFormatter appears to
me missing some flexibility in dealing with other than its own set of
formatting converters, whatever the programmers thought they would need at the
time they wrote it. I looked at a the header file for the class and it is
gigantic, it is an amazing piece of work.
So even when you take numeric values from a couple of NSTextFields and perform
some calculation, the display of those fields is purely string representation
of the underlying values, but the minute you begin doing calculations, you are
back working with the floats, ints, etc. Some systems handle this automatically
for you, some require you to deal with that conversion, keeping track of what's
what, etc.
It's OK that the NSNumberFormatter doesn't have that capability, or at least
that I havent found it, work-arounds have always been a specialty for me, so
that doesn't bother me in the least, I was just trying to explore my way around
Cocoa. The NSDateFormatter has worked very well for me, and showed no such
weakness.
As I mentioned before when displaying the {string, text} representation of the
underlying {item, object} which could be {floats, doubles, ints, etc} the
format is applied, and the result is used for display purposes, whether it be
to the screen, printer, etc., and obviously the formatting does not change in
any way the underlying object.
Assuming there's a method to trigger the conversion, its job is to apply the
format for conversion from object to display representation, and if you pass
the method an NSNumber, and an NSNumberFormatter, then regardless of the source
of that NSNumber, or its intended use, the result should be in the format that
you provide. The formatter should not care, nor does it know anything about
what the number is going to be used for, or where it came from. It does NOT
know, whether you are going to use that number to {add, subtract, etc} or
whatever. It's only function in life is to take a properly structured number in
the form of an NSNumber Object, whether that NSNumber came from a phoneNumber
string, a calculation, etc. It just doesn't matter, its source is irrelevant,
and its target is also irrelevant.
NSString *aNumberString = @"1234567890";
NSString *format = @"(###) ###-####";
NSNumberFormatter *numberFormatter = [[[NSNumberFormatter alloc] init]
autorelease];
[numberFormatter setFormat:format]; // specify just positive values format
NSInteger theInt = [aNumberString intValue];
NSNumber *theNum = [NSNumber numberWithInt:theInt];
NSString *theResultString = (NSString *)[numberFormatter
stringFromNumber:theNum];
The above should work, and the only way this scenario to fail is if there are
additional assumptions/limitations, as to what is allowable within the format
string, and with the type of variable you are dealing with, as shown below.
Using (numberWithInt:theInt), the results show that the class tries to protect
you from your own bufoonery. It senses that you used an NSNumber with integer
contents, and ignores the ".##" portion of the format string. So it is doing
more checking, and prevents you from displaying an integer as a float, unless
of course you force the format as you can see below :
from : format = @"##,###,###.##";
to : format = @"##,###,###.00";
NSUInteger theInt = [aNumberString intValue];
NSNumber *theNum = [NSNumber numberWithInt:theInt];
NSString *aNumberString = @"1234567890";
NSString *format = @"##,###,###.##";
2010-04-15 13:09:34.646 Formatter[771:a0f] [4625] theString = 1,234,567,890
in which case it will let you do that :
NSString *aNumberString = @"1234567890";
NSString *format = @"##,###,###.00";
2010-04-15 13:09:34.646 Formatter[771:a0f] [4625] theString = 1,234,567,890.00
------------------------------------------------------------------------------
If I change the following from (numberWithInt:theInt) to
(numberWithDouble:theDouble) then the outcome is correct :
// NSUInteger theInt = [aNumberString intValue];
// NSNumber *theNum = [NSNumber numberWithInt:theInt];
double theDouble = [aNumberString doubleValue];
NSNumber *theNum = [NSNumber numberWithDouble:theDouble];
NSString *theString = (NSString *)[numberFormatter stringFromNumber:theNum];
--------------------------
and yields :
NSString *aNumberString = @"1234567890.99";
NSString *format = @"$ #,###,###,###.##";
2010-04-15 13:43:25.977 Formatter[1337:a0f] [4625] theString = $
1,234,567,890.99
Which is correct...
------------------------------------------------------------------------------
This next format, as well as some of the others I attempted fail as well (so as
an observation, and not an absolute truth), apparently NSNumberFormatter will
not let you use other than accepted currency formatting characters {$, " ",
",", ".", -} {$, spaces, commas, periods, minus signs, etc} within the format.
NSString *aNumberString = @"1234567890.99";
NSString *format = @"#_###_###_###.##";
2010-04-15 14:13:46.115 Formatter[1442:a0f] [4625] theString = 1234567891
which of course is incorrect.
Anyway, I finally got this to work, but conclude that primarily from what I've
been able to figure out, NSNumberFormatter, unless someone can show otherwise
really is more of an NSCurrencyDisplayFormatter, which is OK, its just fine. I
just needed to understand how to make it work for me...
This whole exercise for me only had to do with trying to learn about one more
little area of Cocoa, and regardless of what else can be said, there was
definitely learning involved.
Obviously the whole Cocoa environment is mind boggling, it is an incredible
feat, I cant even begin to fathom the vision, to reality, and who am I to
question such an amazing piece of work. I am trying to find my way to doing
something useful with it.
Beyond that, I am sure somebody knows the big picture, and has actually seen
it. I spoke to someone the other day about the learning curve with Cocoa, and
they said it was a short trip, somewhere around 20 parsecs...
http://www.wisegeek.com/what-is-a-parsec.htm
Thanks to everybody who helped...
Bil Hernandez
Plano, Texas
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
