> >Well, yeah, that is what I'm thinking about. Seems silly to have m_getfld > >call > >something that sort of looks like m_getfld but is different. Making it work > >down > >to all of the body parts would in my mind be architecturally better for nmh. > > But, > >as you say, more work. > > So why not create a "new and improved" but robust and backwards-compatible > m_getfld > by a different name to implement the new behavior? It can then be tested for > awhile > with the new features and once it proves reliable, replace the existing calls? > (perhaps with an experimental build option for "early adopters" to do so now). > > It's a few more steps, but you otherwise seem to get the best of both worlds? > Modern code for the future without discarding stable spaghetti of the present.
I could do that. But, as I tried to say earlier, I can't do it because I don't *really* understand what m_getfld does. I have a general idea, but not enough to think that I could really duplicate it easily. Jon _______________________________________________ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers