On Fri, Sep 13, 2013 at 12:26 AM, David Jeske <[email protected]> wrote:
> On Thu, Sep 12, 2013 at 2:04 PM, Jonathan S. Shapiro <[email protected]>wrote: > >> The more interesting challenge is to either (a) get people to use some >> form of StringReader for sequential access to strings >> > > To me this seems the saner route. > > If it meant more flexible ways to handle proper I18N, I would be happy > with a cursor-based string-reader. Here you could get a cursor from > start/end or a saved handle, and then increment/decrement the cursor > position, and save any position or range. You would not be able to > fabricate an arbitrary location like is possible with the a[i] API. > > This would prevent C-style "for (i=0;i<length;i++)" loops, but would > support a an iterator style of the same loop "for(cursor=s.start; > cursor.haschar; cursor.inc)", where inside the iterator you could save off > locations easily. > > Whether other folks would find this acceptable or not is another matter. > The problem with this line of reasoning is that it requires the majority of users to give up simple, bad code in order to serve the needs of a small number of users who actually want to do internationalization properly. Even if it's the right thing to do, changes of this kind rarely prosper. Fortunately, it shouldn't be that hard to design a pass that turns "for(i=0; i < length; i++)" and "foreach c in s" into something that uses a StringReader. The main catch with such optimizations is that you don't want them to introduce, say, heap allocation into a NoHeap procedure... shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
