[libpc] RE: exposing capabilities, hiding classes

[Michael P. Gerlek]

(CC'ing the list)

OK, I'll look at that today.  [I assume this is "traits" like char traits in
strings?  I've seen them mentioned, but have never learned anything about
them since I live in an 8-bit, old-fashioned, EN-us only world...]

In any case, I think this should be discussion #1 for the sprint (two weeks
away, yikes) -- I think we can proceed as-is without any undue damage /
excess pain to the future actual model?

-mpg

> -----Original Message-----
> From: Howard Butler [mailto:hobu.inc at gmail.com]
> Sent: Monday, February 28, 2011 7:37 AM
> To: mpg at flaxen.com
> Cc: Michael Smith
> Subject: Re: exposing capabilities, hiding classes
> 
> What about traits-style as an alternative to the A and B you've set up in
the
> email below?
> 
> http://www.boost.org/doc/libs/1_46_0/libs/type_traits/doc/html/boost_ty
> petraits/background.html
> 
> 
> On Feb 25, 2011, at 5:47 PM, Michael P. Gerlek wrote:
> 
> > The idea under discussion is to find a way to not have to expose a
> > zillion different classes to the user -- such as a LAS reader, a
> > decimation filter, an Oracle writer, etc.  The reason for this idea is
because
> (1) it "feels"
> > like exposing too many headers to the user and giving him too much to
> > think about, and (2) every header we "expose" is one more area that we
> > need to worry about keeping clean between releases.
> >
> > To implement this idea, then, we want to expose "capabilities" or
> "features"
> > instead.  (I think of this as letting the user see an "abstract"
> > feature set instead of an actual "implementation".)
> >
> > Consider a workflow where we want to build a pipeline that reads a LAS
> > file, crops it, and writes it out as LAZ using point format 7.  In the
> > current model this would look like:
> >
> >    LasReader reader("foo.las")
> >
> >    Bounds bounds(0,0,0,100,100,100)
> >    Cropper filter(reader, bounds)
> >
> >    LazWriter writer("bar.laz", filter)
> >
> >    writer.write()
> >
> > In the proposed model, this would look something like this:
> >
> >    Stage reader = createStage(READER_LAS)
> >    reader.setInputFile("foo.las")
> >
> >    Stage filter = createStage(FILTER_CROP)
> >    filter.setPrevStage(reader)
> >    Bounds bounds(0,0,0,100,100,100)
> >    filter.setBounds(bounds)
> >
> >    Stage writer = createStage(WRITER_LAZ)
> >    writer.setOutputFile("bar.laz")
> >    writer.setPointType(X)
> >    writer.setPrevStage(writer)
> >
> >    writer.write()
> >
> > In this world, the Stage base class always has these member functions,
> > although setInputFile(), setOutputFile(), setBounds(), and
setPrevStage().
> > They are unimplemented, however, unless
> > Stage.getCapabilities(FEATURE_NAME)==true.  ((In the above example,
> we
> > "know" the feature setInputFile() is available because we specifically
> > asked
> > createStage() for a kind of reader, but in general we would not
> > "know".))
> >
> > (Am I right so far?)
> >
> > In the limit, then, this idea would mean that every new feature we
> > come up with -- be it a writer, reader, or filter -- will have to be
> > supported by the enum we pass to createStage() and possibly also have
> > a corresponding member function in Stage.  This seems to mean that
> > every time we want to add some new kind of operation, we need to
> > modify (extend) a core component for that one new driver feature --
> > such as "setPointType", which only ever makes sense for a LAS writer.
> >
> > Also, consider a libPC user who wants to add his own driver -- say, a
> > particular filter that throws out some points based on his own criteria.
> > Does he have to modify the createStage() and add members to Stage to
> > do this?
> >
> > I *think* I'm therefore against this idea, because we want a library
> > that is very extensible, and we'd constantly be adding new stuff to
> > the base class, which seems to me just as bad as the problem of
> > exposing a zillion Stage-derived classes to the user.
> >
> > So, is there a middle ground, I wonder?
> >
> > -mpg
> >
> >