[Liblas-devel] Design/architecture questions

[Mateusz Loskot]

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