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 >
