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

Reply via email to