[Waba-spec] Re: A Font counter-counter proposal
Status: Abandoned
Brought to you by:
bornet
From: Sean L. <se...@cs...> - 2001-11-28 03:20:21
|
Guilherme quoth: > Maybe you could adopt what i made in SuperWaba. > My String class has this: > /** The bytes are converted to char and vice-versa using the > CharacterConverter associated in this charConverter member. */ > public static waba.sys.CharacterConverter charConverter; > public String(byte[] value, int offset, int count); > public byte[] getBytes(); I like the general idea of supporting the getBytes() function and String(byte[],int,int) constructor. Especially since we'd need to read and write to streams. And you picked exactly the right ones to support (rather than the other myriad of byte-conversion methods). AND I like the idea of a swap-in coder. But I'm a little queasy about adding a data member to a Java-compliant a class as java.lang.String! This really pushes us away from the Java standard rapidly. So where do you stash a swap-in converter if not String? Maybe the best place would be as a static member of the waba.sys.Convert class. A few other quibbles to otherwise a nice idea: > /** This class is used to correctly handle international character > convertions. > * The default character scheme converter is the 8859-1. If you want > to use > a different one, > * you must extend this class, implementing the bytes2chars and > chars2bytes > methods, and then > * assign the public member of java.lang.String charConverter to use > your > class instead of this default one. In a PDA, ISO-8859-1 really *shouldn't* be the default. The default really should be some form which preserves Unicode values, like UTF-8. Unfortunately, Sun's suggested "default" (if your operating system doesn't have anything better) is indeed ISO-8859-1. I think that was a big mistake on their part, but oh well. If we're going the drop-in coding route, we oughta provide, at the very least, free encoders in the core spec which do ASCII, (more critical than others) UTF-8, plus maybe UTF-16BE, UTF-16LE, and UTF-16. That's all the encodings one's expected to see typically anyway, and those can all be done easily without a lookup table. Kaffe's probably got GNU versions of the encodings if you want to grab 'em. > public class CharacterConverter Converter isn't the right word. This should be an encoder, something like CharacterEncoder, or some such. No big deal though. BTW, there's a standard non-public Java class called java.lang.StringCoding, which has almost identical functions as yours, they're called: static byte[] encode(char[] ca, int off, int len); static char[] decode(byte[] ba, int off, int len); ...maybe those would be better names, just a suggestion. Also, I'm not sure if you should override CharacterEncoder, er, CharacterConverter, or if we should have an interface to extend instead, where the default class extending the CharacterEncoder interface is ISO88591Encoder. Dunno about that. Perhaps it wouldn't buy us anything in terms of memory consumption. Sean |