On 01/12/10 18:10, Howard Butler wrote: > A few questions arise: > > * Instead of setting filters and transforms on the > liblas::Reader/liblas::Writer (and caching these lists as data > members on either), what tact should we take?
liblas::Reader is a thin handle giving access to the actual reader operating on LAS data. It does not provide any detailed logic itself, it's just a proxy object to which a specific reader implementation is attached. liblas::ReaderI is the actual definition reader interface and behaviour. Whatever a LAS reader is supposed to do, it should be outlined in ReaderI. Next, there are implementations of the ReaderI and these implementations can be attached to liblas::Reader proxy depending on various circumstances. Given that, liblas::ReaderI is the place where transformation, filtering and all the other behaviour should be specified. How the transformers or filters are handled? It should be up to particular implementation of ReaderI. Some may cache it, some may not, but I don't think ReaderI should cache anything here. It may feels that particular implementations of ReaderI will have repeated members caching transformers and filters, but caching them in ReaderI makes more hassle than it saves on typing. What if I want to have reader implemented in such way that transformers are cached in some special sorted order? > * How do we support injecting a custom header into the pimpl? Right > now, every method on the pimpl takes an explicit header. We know the > custom header at construction time, and we are currently caching it > on the Reader. Should this be moved down into the pimpl to be > cached? Again, IMHO, this is part of ReaderI. If header is a part of object state, it should be passed in ReaderI ctor (factory). If reader operations are independent in such way they can use different headers, then pass header as parameter of those operations. The ReaderI is an interface and it does not care how specific implementors deal with header, they can cache it or not. I'm answering the questions and discussing my ideas of how I see it. I'm not referring current state, how changes may affect users, etc. Disclaimer: I'm strongly against technique called "implementation inheritance". Code reuse based on implementation inheritance is a myth and makes more troubles than it saves on typing. The implementation inheritance is OK as long as it's private and does not make use of substitutability, but this is not the case in ReaderI. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org _______________________________________________ Liblas-devel mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/liblas-devel
