| View previous topic :: View next topic |
| Author |
Message |
John
Joined: 17 Jan 2006
Posts: 75
|
 Posted: Fri Mar 03, 2006 2:01 pm Post subject: Spanking new locale package |
 |
|
Ready to be played with, tossed around and broken is the new mango.locale package, providing culturally appropriate formatting options for text output. http://svn.dsource.org/projects/mango/trunk/mango/locale/.
The aim is to enable applications intended for international audiences to be easier to write. Support is included for 225 cultures - 157 specific to a geographical location, and another 68 neutral cultures. The full list can be found in the ddoc comments in the mango.locale.core module.
There are types for working with date and time, currency and numbers, and also for getting general information about cultures and regions.
It is by no means finished, and is a little rough around the edges, so I'd love your input at this stage. Could it be done better? Is anything glaringly absent (besides string comparison, case conversion and better time zone support)?
I'd also like opinion on how you'd prefer to use the formatting classes. Currently there are two ways to format a number: 1) through the Number struct's format() methods, and 2) through the toString() methods in each struct that represents an actual number (UInt16/Int16/UInt32/Int32/UInt64/Int64/Float32/Float64). There's a third option I've been thinking of, too - moving these methods into the Formatter class. Or do you like having the option of doing things either way? Here's how they look:
| Code: | Number.format(1234.56, "N", Culture.getCulture("en-GB"));
Float32.toString(1234.56, "N", Culture.getCulture("fr-FR"));
// Possible future syntax
Formatter.format(1234.56, "N", Culture.getCulture("es-ES")); |
Please send any bugs or suggestions to me: johnch_atms at hotmail dot com.
While I'm here - does anyone have an algorithm for calculating the start and end dates of daylight saving time under Linux? If you do, bung an email my way (a quick search of my usual resources came up blank).
If you want to find out how to do something with this package, you always can ask here and I'll try to see you right.
John. |
|
| Back to top |
|
 |
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Sat Mar 11, 2006 7:15 pm Post subject: |
|
|
This is awesome!
A question: have you thought about whether to support wchar and dchar in these modules?
An observation: not sure if its worth exposing all the various numeric types ~ I had originally done something similar in mango.convert, and then fell back to just double and long in the end. It condenses the API tremendously, and really loses nothing in terms of performance (for general usage); i.e. the numeric loss in efficiency is likely swamped by other concerns.
Another observation: keeping the various type handlers in seperate modules permits one to pick and choose the code via imports. If everything were in the Formatter class, then all the code will be linked in ~ including FP support. There may well be cases where this is unwarranted and unwanted, so it's perhaps more flexible to keep things isolated.
Again, this looks to be a really sweet package
- Kris |
|
| Back to top |
|
|
John
Joined: 17 Jan 2006
Posts: 75
|
| Posted: Mon Mar 13, 2006 4:09 am Post subject: |
|
|
| Quote: | | have you thought about whether to support wchar and dchar in these modules? |
You seem quite insistent on this, Kris!  So, yes, probably just the formatting classes. I'm guessing that 0.149's new implicit template instantiation won't be of much help here as it doesn't yet work for class function templates.
| Quote: | | not sure if its worth exposing all the various numeric types ... keeping the various type handlers in seperate modules permits one to pick and choose the code via imports |
You're right, of course. I think I've figured out a way to accomplish this via interfaces. Something like this:
| Code: | import mango.locale.fp;
Formatter.forDouble = mango.locale.fp.DoubleFormatter.instance;
Formatter.format("{0} divided by {1} is {2:G4}.", 5, 3, 5.0/3.0); |
forDouble could alternatively point to a delegate. |
|
| Back to top |
|
|
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Mon Mar 13, 2006 1:51 pm Post subject: |
|
|
| John wrote: | | Quote: | | have you thought about whether to support wchar and dchar in these modules? |
You seem quite insistent on this, Kris! So, yes, probably just the formatting classes. I'm guessing that 0.149's new implicit template instantiation won't be of much help here as it doesn't yet work for class function templates |
Oh, the intent was merely to open up the question of wide-char support; see what others think. Frankly, Templates can be a pain in the arse to maintain & debug, but it seems useful to do so anyway. There's no insistence there ~ honest, guv'!  |
|
| Back to top |
|
|
John
Joined: 17 Jan 2006
Posts: 75
|
| Posted: Mon Mar 13, 2006 3:22 pm Post subject: |
|
|
| Personally I just use your toUtf16/toUtf32 methods from Ares. But let's allow democracy its say. |
|
| Back to top |
|
|
teqdruid
Joined: 11 May 2004
Posts: 390
Location: UMD
|
| Posted: Tue Mar 14, 2006 10:17 am Post subject: |
|
|
| John wrote: | | Personally I just use your toUtf16/toUtf32 methods from Ares. But let's allow democracy its say. |
That's not the most efficient method. Plus, this is a locale package.... kinda makes sense for it to natively support more than just UTF8.
~John Demme |
|
| Back to top |
|
|
John
Joined: 17 Jan 2006
Posts: 75
|
| Posted: Wed Mar 15, 2006 4:30 am Post subject: |
|
|
| Quote: | | kinda makes sense for it to natively support more than just UTF8. |
Fair enough.
Not sure I like the template approach for this, though. Is there a way to do a user-overridable alias? Something analogous to the following C macro?
| Code: | | #define TCHAR wchar |
Shame you can't redefine an alias. |
|
| Back to top |
|
|
teqdruid
Joined: 11 May 2004
Posts: 390
Location: UMD
|
| Posted: Wed Mar 15, 2006 9:16 am Post subject: |
|
|
| John wrote: | | Quote: | | kinda makes sense for it to natively support more than just UTF8. |
Fair enough.
Not sure I like the template approach for this, though. Is there a way to do a user-overridable alias? Something analogous to the following C macro?
| Code: | | #define TCHAR wchar |
Shame you can't redefine an alias. |
I proposed a similar thing for Mango awhile back, but Kris poo-poo'ed it. Here it is again:
| Code: |
version(UTF8) {
alias mangoChar char;
} else version(UTF16) {
alias mangoChar wchar;
} else version(UTF32) {
alias mangoChar dchar;
} else {
alias mangoChar char; //Use UTF8 by default
}
|
Then, whenever you have need for a character type, template it, and make mangoChar the default:
| Code: |
class MyStringThingT(T)
{
T[] string;
}
alias MyStringThing!(mangoChar) MyStringThing;
|
So that people can use -version=UTFx when they compile Mango to select their preferred encoding, but can use the template as well.
~John |
|
| Back to top |
|
|
John
Joined: 17 Jan 2006
Posts: 75
|
| Posted: Thu Mar 16, 2006 3:56 am Post subject: |
|
|
That's pretty sweet, John.
It appears you can in fact redefine an alias in two different modules, which I'm sure never used to be possible. At least, it never worked when I tried it in earlier versions.
John C. |
|
| Back to top |
|
|
John
Joined: 17 Jan 2006
Posts: 75
|
| Posted: Thu Mar 16, 2006 2:41 pm Post subject: |
|
|
By the way, I'm thinking of making it so that floating-point code will only get compiled if the expected version label "mlfp" is passed to the compiler. It's simpler than requiring the user to both import the appropriate module and configure the Formatter class with a delegate/interface.
John C. |
|
| Back to top |
|
|
John
Joined: 17 Jan 2006
Posts: 75
|
| Posted: Sun Apr 16, 2006 5:54 am Post subject: Various updates |
|
|
I've updated the package with various new features, among them:
Added the invariant culture: provides formatting info that is not tied to any particular region.
Added culture inheritance: for example, the parent of "en-GB" is "en".
Better date/time parsing: supports more patterns and fixed a major bug.
Added basic collations: provides string comparison and sorting.
Removed numeric formatting and parsing: these will probably come back once I've figured out a nice API for them (string formatting is still there and can be used to accomplish the same thing in a more generic way).
Optional floating point support: a version identifier controls whether FP code is compiled.
Much of the native functionality is still lacking for Linux, so if someone wants to have a go at tackling that, be my guest.
The next update will see support for different encodings. I'll also add some code examples.
John C.
PS - My SVN client was playing up and wouldn't let me upload the changes until I deleted the old versions. SmartSVN - not so smart, then. |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
