Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SR-1602] NSEnergyFormatter needs to be implemented #4149

Closed
phausler opened this issue May 24, 2016 · 8 comments
Closed

[SR-1602] NSEnergyFormatter needs to be implemented #4149

phausler opened this issue May 24, 2016 · 8 comments

Comments

@phausler
Copy link
Member

Previous ID SR-1602
Radar None
Original Reporter @phausler
Type Bug
Status Resolved
Resolution Done

Attachment: Download

Additional Detail from JIRA
Votes 0
Component/s Foundation
Labels Bug, StarterBug
Assignee kweinmeister (JIRA)
Priority Medium

md5: 15c3ead09724965718f9d9f425a69968

Issue Description:

NSEnergyFormatter is a relatively simple class with conversions to and from a base unit of joules internally. Many of the methods in swift-corelibs-foundation for this class have placeholder implementations marked with NSUnimplemented. This is highly testable and a relatively simple behavior.

@swift-ci
Copy link
Contributor

swift-ci commented Jun 3, 2016

Comment by Matthew Spear (JIRA)

First time contributor - I'm going to start work on this and will see how I get on!

@swift-ci
Copy link
Contributor

swift-ci commented Jun 4, 2016

Comment by Matthew Spear (JIRA)

I've started work implementing some of the methods - https://github.com/Matthewspear/swift-corelibs-foundation

Taken the approach of using a pair of dictionaries to store the strings of units - Is this the best approach?

Putting it in nested dictionary is efficient as in ~ O(1) access but isn't very pleasing having to explicitly unwrap the components another approach would be a massive switch statement but I not sure how efficient that would be either?

I could do with some feedback, and to see if I going in right direction!

@phausler
Copy link
Member Author

phausler commented Jun 4, 2016

Internally Foundation actually uses an internal class NSUnitFormatter, which uses a dictionary to store it's unit to value association so that is practically on track.

The only differential is that it uses icu to do some of the string conversions. One note to consider is that localization should come into play.

[self.numberFormatter.locale objectForKey:NSLocaleUsesMetricSystem] should come into play for almost all of the string conversions.

@phausler
Copy link
Member Author

phausler commented Jun 4, 2016

It might be interesting to test with en_GB, fr_FR, en_US, and zh_CN; that should test a few portions like number formatting and the localizations of units that might not be picked up with your system locale (some countries have differing rules).

Here is a dump of some of the localized strings associated with formatting energy.
formatters.swift

@swift-ci
Copy link
Contributor

Comment by Matthew Spear (JIRA)

What is the roadmap for NS....Formatter classes? Specifically in relation to the newly introduced NSMeasurements (et al) in Foundation which were mentioned at WWDC.

How does the transfer of ideas from Foundation to the Swift Foundation project happen?
Would that mean deprecation of the unit specific formatters (NSLengthFormatter, NSMassFormatter, NSEnergyFormatter ...)?

@swift-ci
Copy link
Contributor

swift-ci commented Jul 5, 2016

Comment by Matthew Spear (JIRA)

Hey @phausler ^ re-question above - sorry to ping you in just need some input on if this is worth my working on or if it will be deprecated soon?

Thanks,
Matt

@swift-ci
Copy link
Contributor

Comment by Karl Weinmeister (JIRA)

Created PR 791. Reassigned due to inactivity.

@swift-ci
Copy link
Contributor

swift-ci commented Apr 7, 2017

Comment by Karl Weinmeister (JIRA)

PR Merged Feb 10. Closing.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@shahmishal shahmishal transferred this issue from apple/swift May 5, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants