I know I recommended implementing this patch this way, but now I'm wondering if I'm right.
The parser picks up as much data as it can from the input modules, and the docset is responsible for using a formatter to write the data which should be included in the docset.
It seems like a natural extension to this design to say that the parser controls what content is available to the docset(s). That would indicate that this option should change the behavior of the parser, not the docset. A side effect of doing it this way is the feature will be available (enforced) with *all* docsets.
I'm not sure where to draw the line on this sort of thing, but want to discuss it before accepting this patch. (There's no other reason I wouldn't accept it, I just want to be comfortable with the design first.)
What do you think?
Doug
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That is approximately the way I thought it should be done until you told me otherwise. But thinking about it now, this
should be implemented as a new kind of class: a ParseTreeFilter. There might be more of these in the future.
I went with your thoughts only because I saw that all docsets were descending from one ancestor, making it easy
to implement my changes in one class.
I might have another look at this, but I also have my normal
job to do... Give it some time. :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I like your ParseTreeFilter idea even better. I have also started thinking about how
to plug extra behavior into the parser itself. There are already several steps it follows
to extract information, and the filtering could be a special step or could just occur by
leaving out some other steps.
Another way to implement it would be to use the full parser to always gather all
information, but then have the filter wrap up the parser before it is handed to
the docset. The filters could be piped together by muliple layers of nesting the
instances.
I'll think some more on it, but I like this direction better than making each docset
do the work.
Doug
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
None
I know I recommended implementing this patch this way, but now I'm wondering if I'm right.
The parser picks up as much data as it can from the input modules, and the docset is responsible for using a formatter to write the data which should be included in the docset.
It seems like a natural extension to this design to say that the parser controls what content is available to the docset(s). That would indicate that this option should change the behavior of the parser, not the docset. A side effect of doing it this way is the feature will be available (enforced) with *all* docsets.
I'm not sure where to draw the line on this sort of thing, but want to discuss it before accepting this patch. (There's no other reason I wouldn't accept it, I just want to be comfortable with the design first.)
What do you think?
Doug
That is approximately the way I thought it should be done until you told me otherwise. But thinking about it now, this
should be implemented as a new kind of class: a ParseTreeFilter. There might be more of these in the future.
I went with your thoughts only because I saw that all docsets were descending from one ancestor, making it easy
to implement my changes in one class.
I might have another look at this, but I also have my normal
job to do... Give it some time. :-)
I like your ParseTreeFilter idea even better. I have also started thinking about how
to plug extra behavior into the parser itself. There are already several steps it follows
to extract information, and the filtering could be a special step or could just occur by
leaving out some other steps.
Another way to implement it would be to use the full parser to always gather all
information, but then have the filter wrap up the parser before it is handed to
the docset. The filters could be piped together by muliple layers of nesting the
instances.
I'll think some more on it, but I like this direction better than making each docset
do the work.
Doug
I've implemented this, but using --no_private_names as the switch instead of -P.