I understand Java's intent re the *byte* type, and i agree that Java's use
of Unicode is a long-overdue move to non-Anglo-centric computing. However,
since i've been writing rock-solid C code for almost 20 years, i've long
observed a common programmer laziness concerning all numeric types -- namely
the non-use of the "unsigned" qualifier for inherently unsigned numbers
(e.g. file offsets, binary file contents). The former example created an
unnecessary 32KB (and later 2GB) limit to file sizes handled using the
standard C library. The latter example is still an issue today -- at least
for those whose computing environment includes low-resource embedded systems
and/or legacy byte-oriented data formats.
I beg to disagree that 16-bit characters are always the better approach when
dealing with byte-oriented data. It is true that modern 32- and 64-bit
processors don't handle mere bytes as efficiently as the 8- and 16-bit procs
of old, and thus should use 16-, or even 32-bit, chunks as the base unit of
data. However, if Java is going to cover the world, including embedded
systems (e.g. the Java coffer-maker), compact byte-oriented data formats
will continue to be useful
Traceback (most recent call last):
File "./app.py", line 362, in browse_fs
data = list_dir(request.values["path"])
File "lib/util/filesystem.py", line 68, in list_dir
item["speech"] = items[idx].quack()
AttributeError: Snake instance has no attribute 'quack'