I'm fine with either option. Deprecating methods of private classes isn't useful IMHO bit I suppose extra 'nice' for users doing things they shouldn't.
> On Dec 4, 2015, at 12:50 PM, Apekshit Sharma <a...@cloudera.com> wrote: > > Ahh.. if I had mentioned it earlier, there wouldn't have been any confusion. > > So the thing is, earlier patches (up to v6) are deleting the functions which > take byte[] or String as argument. > These are like 15 or so 'useless' functions and I believe it's okay to > delete them. > > Later I updated the patch (v7-v8) to mark them deprecated (instead of > deleting) to decouple that jira from discussion [1] > > @Andrew: which patch did you look at? Can you please confirm your take on > this. > > Thanks. > > [1] > https://issues.apache.org/jira/browse/HBASE-14769?focusedCommentId=15032734&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15032734 > > On Wed, Dec 2, 2015 at 5:32 PM, Andrew Purtell <andrew.purt...@gmail.com> > wrote: > >> Ok, so no annotation change then. I looked at HBASE-14769. Change there >> seems fine. >> >> >>> On Dec 2, 2015, at 5:03 PM, Apekshit Sharma <a...@cloudera.com> wrote: >>> >>> In this particular case, we are deleting functions in HBaseAdmin which >> take >>> byte[] or String as argument. >>> HBASE-14769 >>> >>> On Wed, Dec 2, 2015 at 4:56 PM, Andrew Purtell <andrew.purt...@gmail.com >>> >>> wrote: >>> >>>> We also might want to fix the annotation. Like Stack said it depends on >>>> the particulars. I suggest filing a JIRA. >>>> >>>>> On Dec 2, 2015, at 4:36 PM, Stack <st...@duboce.net> wrote: >>>>> >>>>> Appy makes a pretty good argument. >>>>> >>>>> What in particular are we discussing Ashish? >>>>> >>>>> Thanks, >>>>> St.Ack >>>>> >>>>>> On Wed, Dec 2, 2015 at 3:49 PM, Apekshit Sharma <a...@cloudera.com> >>>> wrote: >>>>>> >>>>>> I think it should be okay to remove them. When I imagine myself on >> other >>>>>> side, a dev using client api of Foo project, and I see a class >> returning >>>>>> reference to an internal class, I would not trust that function. If I >>>>>> really need something from returned ref, I'd probably use it, and if >> it >>>>>> goes away tomorrow, i'd probably curse it too, but I can't complain >>>> since >>>>>> it's not anything I trusted to being with. >>>>>> >>>>>> Now thinking as dev: >>>>>> Given that documentation explicitly states that functions can >> disappear >>>>>> from private class, and nothing about transitiveness, I believe we can >>>>>> remove functions from private class A. >>>>>> >>>>>> >>>>>>> On Thu, Nov 26, 2015 at 7:10 AM, Ted Yu <yuzhih...@gmail.com> wrote: >>>>>>> >>>>>>> bq. we should not remove it directly >>>>>>> >>>>>>> My understanding is the same. >>>>>>> >>>>>>> Cheers >>>>>>> >>>>>>> On Wed, Nov 25, 2015 at 10:22 PM, ashish singhi < >>>>>> ashish.sin...@huawei.com> >>>>>>> wrote: >>>>>>> >>>>>>>> Hello to all. >>>>>>>> >>>>>>>> I know that we can safely remove any APIs from a >>>>>>> InterfaceAudience.Private >>>>>>>> class and the same is described in the HBase book. >>>>>>>> >>>>>>>> Now consider a case (I did not find this mentioned in our semvar), >>>>>>>> There is a class 'A' with InterfaceAudience.Private and class 'B' >> with >>>>>>>> InterfaceAudience.Public and then there is a public API in class 'B' >>>>>>> which >>>>>>>> returns an instance of class 'A'. (We missed to mark the public >> method >>>>>> in >>>>>>>> class 'B' as deprecated when we marked the class 'A' as >>>>>>>> InterfaceAudience.Private). >>>>>>>> >>>>>>>> Now the question is, can we remove the public APIs from class 'A' >>>>>> without >>>>>>>> marking them deprecated ? >>>>>>>> >>>>>>>> I think we should not remove it directly, it will break the users >>>> using >>>>>>>> these(removed) public methods from class 'A'. >>>>>>>> P.S: This point came up in HBASE-14769. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Ashish Singhi >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Regards >>>>>> >>>>>> Apekshit Sharma | Software Engineer, Cloudera | Palo Alto, California >> | >>>>>> 650-963-6311 >>> >>> >>> >>> -- >>> >>> Regards >>> >>> Apekshit Sharma | Software Engineer, Cloudera | Palo Alto, California | >>> 650-963-6311 > > > > -- > > Regards > > Apekshit Sharma | Software Engineer, Cloudera | Palo Alto, California | > 650-963-6311
