On Mon, Nov 19, 2012 at 1:57 PM, Johnathan Corgan <[email protected]> wrote: > On Mon, Nov 19, 2012 at 9:22 AM, Ed Criscuolo <[email protected]> > wrote: > >> >> I agree that changing the way gr_iir_filter takes in the taps could >> be disruptive, unless backward compatibility is maintained. Some of >> the group are using GnuRadio for operational systems. > > > Yes. > >> >> Here's two more suggestions for solutions: >> >> 1. Add an optional flag parameter to the constructor, with values >> of "Old_API" and "New_API", with the default set to "Old_API". >> This flag would control how gr_iif_filter interprets the taps. >> It could be maintained this way for some time, with the Old_API >> being deprecated, and eventually change the default to >> New_API, or even make the default a cmake option. >> >> 2. Create two subclasses of filter taps that are identical in >> format, and use C++ overloading to determine which constructor >> or set method to use. > > > I think the first is most straightfoward and consistent with how we've make > API changes in the past. > > Johnathan
Agreed. That's a pretty sane way of helping make the transition. An argument to the constructor should make people perk up and pay attention to the fact that there is a change. Tom _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
