nobu.nokada / softhome.net wrote in message news:<200402181005.i1IA5OrT013173 / sharui.nakada.niregi.kanuma.tochigi.jp>...
> At Tue, 17 Feb 2004 06:24:59 +0900,
> Sean Russell wrote in [ruby-talk:92998]:
> > Well... the patch in 01960 undoes a bunch of work that was done
> > specifically to fix some encoding problems.  It may have created new
> > encoding support problems, but at least the new code is going in the
> > right direction.
> 
> Could you elaborate it?

Sure.

The new code uses IConv, which is now a standard part of Ruby.  UConv
is, AFAIK, obsolete, in addition to requiring a separate download and
install.

The old code was sort of a hack that looked for files named a certain
way in a certain directory, loaded and evaluated them, and required
that each did a certain amount of fairly redundant housekeeping to
register themselves with the encoding engine.  The new code requires a
bit of funny syntax, but otherwise is straightforward mixin code, and
the encodings are discovered dynamically when they're needed, with no
searching through the filesystem.

The old code handled encodings via aliasing a method to the
decoding/encoding methods.  This was not thread-safe fixable except
via Method objects or eval(), both of which are way too slow to be
used in the encoding algorithm, which is a frequently called bit of
code.

Each encoding required two files.  Yuck.

The new encoding code is pretty ugly, too, and I may give up and drop
the mixin metaphor.  However, I need to test the code in a threaded
environment.  I tried to use the singleton pattern when I implemented
the new code, and I believe that it is thread-safe.  It is not very
efficient to set an encoding, but I doubt that this will have much
overall impact on program execution; much more time will be spent in
parsing, which is what I optimized the encoding support for.

Finally, I need to test whether using an encoding object, rather than
trying to mix-in methods, would be much slower.  It would add
overhead, since it would add a method call and method calls are
respectively slow operations.  This would simplify the code
significantly, but (again) REXML has enough problems with speed issues
without me aggrevating it with numerous little lags like this.