hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apekshit Sharma <a...@cloudera.com>
Subject Re: Consesus on removing a public method from IA.Private class whose instance is returned from IA.public class.
Date Fri, 04 Dec 2015 20:50:08 GMT
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.purtell@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 <appy@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 <stack@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 <appy@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 <yuzhihong@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message