You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by Apekshit Sharma <ap...@cloudera.com> on 2015/12/03 00:49:41 UTC
Re: Consesus on removing a public method from IA.Private class whose
instance is returned from IA.public class.
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 <yu...@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 <as...@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
Re: Consesus on removing a public method from IA.Private class whose instance is returned from IA.public class.
Posted by Andrew Purtell <an...@gmail.com>.
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 <ap...@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 <an...@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 <ap...@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.purtell@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 <ap...@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 <yu...@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.singhi@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
Re: Consesus on removing a public method from IA.Private class whose
instance is returned from IA.public class.
Posted by Apekshit Sharma <ap...@cloudera.com>.
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 <an...@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 <ap...@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.purtell@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 <ap...@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 <yu...@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.singhi@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
Re: Consesus on removing a public method from IA.Private class whose instance is returned from IA.public class.
Posted by Andrew Purtell <an...@gmail.com>.
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 <ap...@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 <an...@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 <ap...@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 <yu...@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.singhi@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
Re: Consesus on removing a public method from IA.Private class whose
instance is returned from IA.public class.
Posted by Apekshit Sharma <ap...@cloudera.com>.
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 <an...@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 <ap...@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 <yu...@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.singhi@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
Re: Consesus on removing a public method from IA.Private class whose instance is returned from IA.public class.
Posted by Andrew Purtell <an...@gmail.com>.
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 <ap...@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 <yu...@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.singhi@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
>>
RE: Consesus on removing a public method from IA.Private class
whose instance is returned from IA.public class.
Posted by ashish singhi <as...@huawei.com>.
Sorry for the late response. I was on vacation.
St.Ack:
Class 'A' is HBaseAdmin and class 'B' is HBaseTestingUtility.
I was thinking this from a general perspective, irrespective of the classes and can note it down in our book and avoid this kind of discussions in dev mailing list in future. But seems like we have agreed to take up the call based on the particulars.
Regards,
Ashish Singhi
-----Original Message-----
From: saint.ack@gmail.com [mailto:saint.ack@gmail.com] On Behalf Of Stack
Sent: 03 December 2015 06:07
To: HBase Dev List
Subject: Re: Consesus on removing a public method from IA.Private class whose instance is returned from IA.public class.
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 <ap...@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 <yu...@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.singhi@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
>
Re: Consesus on removing a public method from IA.Private class whose
instance is returned from IA.public class.
Posted by Stack <st...@duboce.net>.
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 <ap...@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 <yu...@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.singhi@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
>