I agree with Oleg, please consider contributing as joining a community, not just providing source code.
Otherwise, a code dump can just happen anywhere. Gary On Tue, Mar 16, 2021, 09:24 Oleg Kalnichevski <[email protected]> wrote: > On Tue, 2021-03-16 at 13:28 +0100, Julian Reschke wrote: > > Am 15.03.2021 um 19:50 schrieb Oleg Kalnichevski: > > > ... > > > Hi Julian > > > > > > Pretty much all message parsing routines in core [1] and client are > > > based on Tokenizer [2]. Those parsers are forward-only and produce > > > near > > > zero (or fairly little) intermediate garbage. > > > > > > Id would be nice if parsing code in Structured Field Values re-used > > > some of the message element parsers or were based on the Tokenizer > > > if > > > possible. > > > > > > Oleg > > > ... > > > > Re-using existing message element parsers would not work; structured > > fields is a new format and requires draconic error handling. > > > > Also, the parser internally is based on java.nio.CharBuffer, using it > > in > > a forward-only way (if I understand the term correctly), and only > > allocates objects in order to build the resulting object model (which > > can be quite complex in structured-fields). > > > > It's probably *possible* to rewrite all of this in order to re-use > > some > > existing code, but then it's somewhat unclear how this would make it > > in > > any way better. > > > > Best regards, Julian > > > > It may not necessarily make it any better, but it would most certainly > make new code more consistent with the rest of the code base, so that > poor suckers like myself who maintain the library on a day by day basis > might have a bit easier life maintaining your contribution. > > This also makes it somewhat unclear why one would want to contribute > new code without making an effort of fitting it into the existing code > base. > > This is a not a deal breaker, just a request for your consideration. > > We have a history of various people dropping a large chunks of code on > us and walking away, leaving us with a thankless task of maintaining > their original code for years to come. So far, if the past history is > of any indication, all those contributions inevitably started to rot > unless they fit well with the rest of the code base. > > Oleg > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
