String formating/parsing
brian
5 Nov 2007
Actually I'm having second thoughts about this design - my gut tells me that it is better to have toStr return a uniform programmatic string. For instance, I think it is wrong to have Bool.toStr to return "vrai" or "faux" in a French locale. By making toStr return a localized representation I think we might fall into the Java String.toUpperCase trap.
So to keep things extremely clear at the expense of a bit longer API names:
toStr, fromStr - programmatic encoding/decoding toFormat, fromFormat - locale formatted encoding/decoding or toLocale, fromLocale - locale formatted encoding/decoding
brian
5 Nov 2007
Decisions from tonight's brainstorm:
To/From APIs
- toStr/fromStr used for programmatic string encoding
- toLocale/fromLocale used for formatted locale string encoding
Locale We are going to enhance interpolation to insert localized properties directly - most likely using a double $ symbol. Some ideas:
out.w("<input name='$^submit' />")
out.w("<input name='$~submit' />")
out.w("<input name='$!submit' />")
out.w("<input name='$^lang::submit' />")
out.w("<input name='$~lang::submit' />")
out.w("<input name='$!lang::submit' />")
API conventions Any API which is locale aware is prefixed with locale (other than toLocale and fromLocale):
Weekday.localeAbbr Weekday.localeFull Weekday.localeStartDay Weekday.toLocale(Str) // uses same WWW, WWW pattern as DateTime Str.localeUpper Str.localeLower Str.localeCompare
brian
3 Nov 2007
Today parse/toStr are the methods used by simples for string encoding and decoding. But we also need a provide human, localized parsing and formating. Human string formating may also require arguments such as a Float decimal or DateTime pattern.
After some discussion, we decided to deal with these using two different sets of methods:
Since many objects can have their localized encoding tailored, we will add an Obj argument to the toStr method. Subclasses can use this objects as they desire as kind of a dynamically typed argument.