Re: [jira] Resolved: (LUCENE-796) Change Visibility of fields[] in MultiFieldQueryParser
: I'm not sure if this applies to this issue, but ISTM that a "private : unless you bug the devs" approach to variable scoping is a little odd. : A few unecessary "private"s sprinkled through the code can really : wreck havoc on effects to extend functionality cleanly. This has the trade off is that once something is "protected" it can never be removed or changed in any significant way -- making it really hard to safely make some optimizations. by saying "let's assume things are private until someone demonstrates a need to deal with it in a subclass" we can at least delay the question of extensibility/performance until it actually becomes relevent. : What if maintaining backward-compatibility of the "inheritance : interface" of classes was explicitly not guaranteed--would this allow : the default policy for new code to use protected rather than private : (unless there is a reason for the latter)? 6 vs 0.6 dozen ... if he "inheritance interface" isn't garunteed, what's the point of having something be protected? -- compilation errors are better protection against people doing something not garunteed then verbage in docs -- if people are willing to depend on something that may not be supported in teh future, they might as well make a local patchto change the visibility. : A class is either designed for extensibility in mind (or certain : kinds), or not at all. It is perhaps unrealistic to audit all lucene the key is "certain kinds" ... classes can be made extensible with the intent of changing behavior A, but with the assumption that behavior B will not be changed, and can be tweaked under the covers later -- the best way to do that is to make the data for A protected, and the data for B private. -Hoss - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Resolved: (LUCENE-796) Change Visibility of fields[] in MultiFieldQueryParser
On 4/4/07, Otis Gospodnetic (JIRA) <[EMAIL PROTECTED]> wrote: [ https://issues.apache.org/jira/browse/LUCENE-796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otis Gospodnetic resolved LUCENE-796. - Resolution: Fixed Makes sense. Thanks Steve, applied. I left those 2 private attributes of MFQP as private until somebody asks for them to be protected. I'm not sure if this applies to this issue, but ISTM that a "private unless you bug the devs" approach to variable scoping is a little odd. A few unecessary "private"s sprinkled through the code can really wreck havoc on effects to extend functionality cleanly. This has caused me grief in the past, and waiting for a lucene release isn't usually a good solution--c&p is faster. What if maintaining backward-compatibility of the "inheritance interface" of classes was explicitly not guaranteed--would this allow the default policy for new code to use protected rather than private (unless there is a reason for the latter)? A class is either designed for extensibility in mind (or certain kinds), or not at all. It is perhaps unrealistic to audit all lucene classes, but perhaps a whole class could be opened up when a bug report is filed? FWIW: $ find -name \*.java | xargs grep private | wc 914 $ find -name \*.java | xargs grep protected | wc 260 cheers, -Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (LUCENE-796) Change Visibility of fields[] in MultiFieldQueryParser
[ https://issues.apache.org/jira/browse/LUCENE-796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otis Gospodnetic resolved LUCENE-796. - Resolution: Fixed Makes sense. Thanks Steve, applied. I left those 2 private attributes of MFQP as private until somebody asks for them to be protected. > Change Visibility of fields[] in MultiFieldQueryParser > -- > > Key: LUCENE-796 > URL: https://issues.apache.org/jira/browse/LUCENE-796 > Project: Lucene - Java > Issue Type: Improvement > Components: QueryParser >Affects Versions: 2.1 > Environment: not important >Reporter: Oliver Hummel > Fix For: 2.2 > > Attachments: LUCENE-796.txt > > > In MultiFieldQueryParser the two methods > protected Query getFuzzyQuery(String field, String termStr, float > minSimilarity) throws ParseException > protected Query getWildcardQuery(String field, String termStr) throws > ParseException > are intended to be overwritten if one would like to avoid fuzzy and wildcard > queries. However, the String[] fields attribute of this class is private and > hence it is not accessible in subclasses of MFQParser. If you just change it > to protected this issue should be solved. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
