[e-lang] Joe-E ByteArray stream interface and character encoding/decoding

[Tyler Close]

Just the size of the API discouraged me from attempting this taming.
For example, checking that Charset really is Powerless requires a
close look given Javadoc comments like:

"except that it is potentially more efficient because it can cache
decoders between successive invocations."

seen on the Charset.decode() method.

Long term, it's probably better to do this work and provide more of
the flexibility of the Charset API.

--Tyler

On 10/16/07, David Wagner <daw at cs.berkeley.edu> wrote:
> Adrian Mettler writes:
> >Here are the proposed implementations for stream adapter logic in
> >ByteArray and character encoding/decoding routines to and from ASCII and
> >UTF-8 in Joe-E.  Tyler suggested that I let you take a look at them and
> >see if there are any unintended bugs or sources of nondeterminism.
>
> Looks fine to me.
>
> Out of curiousity, do we need classes ASCII and UTF8 and their methods?
> Would it be enough to have
>
>     public static final Charset ASCIIcharset = Charset.forName("US-ASCII");
>     public static final Charset UTF8charset = Charset.forName("UTF-8");
>
> somewhere, and then tame Charset, allowing the rest of the methods to
> be implemented in Joe-E rather than in trusted Joe-E libraries?  This is
> a tangent, not an objection to adopting these libraries, so please don't
> let it stop you from adopting these proposed implementations; I'm just
> curious.
> _______________________________________________
> e-lang mailing list
> e-lang at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/e-lang
>


-- 
The web-calculus is the union of REST and capability-based security:
http://www.waterken.com/dev/Web/

Name your trusted sites to distinguish them from phishing sites.
https://addons.mozilla.org/firefox/957/