> On Mar 21, 2016, at 12:36 PM, Matthias Vallentin <vallen...@icir.org> wrote: > > The "implementation detail" maxim lead to artifacts like PIMPL. This > certainly made sense at the time where we considered multiple messaging > backends. At this point, we are invested into CAF, and I don't think > switching will happen anytime soon. Therefore, I don't think we need to > keep up the implementation-hiding abstractions, such as PIMPL, which > come at the cost of development productivity and performance (they are > essentially a compiler firewall due to type erasure).
A possible benefit to PIMPL is improving ability to maintain binary compatibility across releases (i.e. programs dynamically linked to Broker don’t need a recompile if a new release is binary compatible). Providing stable-ish ABIs seems like something libraries often do, so I tried to plan that in to Broker. Don’t know if I did that well, or there’s better strategies to use, or I was the only one worried about that to begin with, but thought I’d mention it just in case it wasn’t even on your radar. - Jon _______________________________________________ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
