Costin Manolache wrote:
On 3/3/08, Remy Maucherat <[EMAIL PROTECTED]> wrote:
On Mon, 2008-03-03 at 15:58 -0700, Filip Hanik - Dev Lists wrote:
Remy Maucherat wrote:
This problem is a small detail. Much more should be done if you want
to
do a refactoring: both the mark functionality and readLine need to
have
direct access to the buffer to be able to be coded in a sane way (and
be
more efficient too).
yes, so the question is for 6.0.x and 5.5.x, do we wanna proceed down
the refactor route?
I was against it in the beginning for the fear of regression. I
personally think the whole bytechunk/charchunk thing is very complex,
and can be done easier, but that is something I would play around in
sandbox, and eventually bring into trunk if it was working.
I am not really interested in participating. Besides some possible
simple cleanup, CharChunk is actually too simple rather than too complex
(ByteChunk is just fine, and doesn't need additional features): to
improve, it would need to get mark capabilities and (unfortunately) get
a readLine (it's even more problematic to implement it outside the
class). I am pretty sure using the NIO buffers will be proposed for some
reason, which are horrible to use as far as I am concerned.
I think the byte->char conversion should be cleaned, the InputStream hack
was
needed 9 years ago because regular conversion sucked and we couldn't use
the
convertors directly. I've seen quite a few other projects doing the
conversion
themself at least for UTF8 and 8859-1.
no one disagrees with that. It's just that 5.5.x and 6.0.x is not the
place for that cleanup.
Regarding using NIO buffers - I agree with Remy, the flip()s are horrible,
I think
there is a version in sandbox that replaces byte[] with the ByteBuffers, and
it doesn't
seem to be worth it.
However I think it would be just great to start making a distinction between
'buffer' and
'pointer to a buffer' - IMO that's the main cause of complexity.
absolutely.
And maybe
add
'implements CharSequence, Appendable' to make the coyote classes more
friendly for
direct use.
for 6.0.x and 5.5.x, I'd rather keep the fixes to the actual bug fix to
maintain stability
There's no way this sort of work could be good for these branches.
Since I'm quite out of sync - what is the current 'dev branch' and is there
any
'some API changes allowed' release planned ?
Costin
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.516 / Virus Database: 269.21.3/1307 - Release Date: 3/2/2008 3:59 PM
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
