Filter by package

[paul-bennett]

Add a command line option, maybe --package-filter that causes Juggle to only list elements (classes or members) that are declared in a package that matches the filter.

The filter should be a literal name with optional trailing .* glob pattern, or a regular expression surrounded by //. Multiple filters may be supplied, separated by commas or in their own options, and a package matches if it matches any of the filters.

Examples:

• --package-filter java.util
• --package-filter java.*
• --package-filter java.*,javax.*
• --package-filter java.* --package-filter jdk.*
• --package-filter /^j/

Consider also allowing negative filters, maybe:

• --package-filter !sun.*

[paul-bennett]

Consider adding --class-filter at the same time (half-implemented but removed by paul-bennett/juggle-2#92).

[paul-bennett]

Could also add --module-filter to complete the containment hierarchy

[paul-bennett]

This ought to be straightforward now that Juggler has the concept of candidate processors.

[paul-bennett]

Although fixing paul-bennett/juggle-2#72 (don't show implementation classes) has eliminated the immediate need for negative package matches, this still seems like a good extension of the original feature.

However, while positive filters are naturally joined with a disjunction (a candidate matches if it matches any filter), negative matches are more appropriately composed with a conjunction (a candidate matches if it fails to match all of the negative patterns). A mixture of positive and negative filters complicates this further. (I believe the best approach would be to accept a candidate that matches all the positive patterns and none of the negatives. In a way this is demonstrates that humans inter DeMorgan's law instinctively.)

But what if you wanted to combine filters in other ways? This risks expanding into a new filter syntax.

Much more thought, and preferably concrete use cases required.

Will drop from juggle-1 milestone.

[paul-bennett]

Since name patterns in queries (‘/foo/`) are matched against the full canonical name of a member, including its containing package, is this feature even necessary?