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.
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
toLocale, fromLocale - locale formatted encoding/decoding
Decisions from tonight's brainstorm:
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.toLocale(Str) // uses same WWW, WWW pattern as DateTime
Login or Signup to reply.