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:
encode/decode are used to deal with programmatic string encoding for simples
toStr/parse are used to deal with localized, human string encodings
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.
brianMon 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:
brian Sat 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.
brian Mon 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:
brian Mon 5 Nov 2007
Decisions from tonight's brainstorm:
To/From APIs
Locale We are going to enhance interpolation to insert localized properties directly - most likely using a double $ symbol. Some ideas:
API conventions Any API which is locale aware is prefixed with locale (other than toLocale and fromLocale):