Miles Elam wrote:
In other words, the pipeline is full of side effects and dependant upon things happening behind the curtain (to use a Wizard of Oz reference). You'd be right in that it adds to the confusion. I agree with Vadim. This is obfuscation in exchange for two lines of verboseness.
Just some additional precisions, "mon fr�re" !
I hope it wasn't taken the wrong way. I did not intend any offense.
Yes, the pipeline is full of side effects, which can break pipelines at any point an continue somewhere else without this being explicitely visible in the pipeline construction statements.
These side effects are called "views", and the way to define views is through labels.
Don't get me wrong. I see clearly the reason why views exist. I see clearly why reader views are wanted. When working with XML data -- not just text, but structured text -- getting at that data before it is processed into a presentation format (such as viewing source, getting a true content view, etc.) can prove invaluable.
And even worse : labels can be placed on component definitions, meaning a clean pipeline with no label attribute at all is full of these side effects.
So what you call obfuscation has been there *for years*. And everybody's happy with it.
When grabbing from the presentation format as a source, you are comparing apples and oranges. Not only are there innumerable binary formats out there being squeezed into a few reader implementations, but they are not all desirable data. While you may want the data from a PDF file, you may not bother with a PNG image because it may index "Created with The Gimp" over and over.
Since putting in all binary format-to-generator mapping info seems out of the question, all of the pipeline path must be specified in the matcher -- hence the discussion surrounding readers and generators in the same matcher. If everything is specified in the same matcher and not truly orthogonal, as is the case for views currently, why add the extra syntax for what amounts to a non-orthogonal if-else clause?
if (!content-view) read else generate transform serialize
as opposed to
generate +---------- view-short-curcuit! --+-> transform-x transform-1 +-> serialize transform-2 serialize
There is a discontinuity there that makes me uncomfortable. This is not an overt attachment to symmetry. This is seeing the same tool applied to two (in my opinion) very different tasks. I am not a committer and can't vote. But these are my thoughts on the matter. Take with as many grains of salt as are necessary.
- Miles Elam
