[ 
https://issues.apache.org/jira/browse/SOLR-14680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17188287#comment-17188287
 ] 

Andrzej Bialecki commented on SOLR-14680:
-----------------------------------------

bq. why bother with getX()

To make the intent clear, and to avoid mixing the naming conventions used by 
all other read-only classes in Solr (and basically everywhere) that follow this 
pattern.

bq. How do you use new interfaces if they do not exist in the first place?

My proposal is this: let's revert this from 8x for the moment, until the API is 
stabilized. In the meantime let's try using this API in master to see if it 
actually works well and is complete enough.

(This was my point earlier about master being the right place to develop new 
APIs).

> Provide simple interfaces to our concrete SolrCloud classes
> -----------------------------------------------------------
>
>                 Key: SOLR-14680
>                 URL: https://issues.apache.org/jira/browse/SOLR-14680
>             Project: Solr
>          Issue Type: Improvement
>            Reporter: Noble Paul
>            Assignee: Noble Paul
>            Priority: Minor
>              Labels: clean-api
>          Time Spent: 10.5h
>  Remaining Estimate: 0h
>
> All our current implementations of SolrCloud such as 
> # ClusterState
> # DocCollection
> # Slice
> # Replica
> etc are concrete classes. Providing alternate implementations or wrappers is 
> extremely difficult. 
> SOLR-14613 is attempting to create  such interfaces to make their sdk simpler
> The objective is not to have a comprehensive set of methods in these 
> interfaces. We will start out with a subset of required interfaces. We 
> guarantee is that signatures of methods in these interfaces will not be 
> deleted/changed . But we may add more methods as and when it suits us



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

Reply via email to