apex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bhupesh Chawda <bhup...@datatorrent.com>
Subject Re: Backward compatibility issue in 3.6.0 release
Date Tue, 30 May 2017 17:51:11 GMT
Can we conclude this thread with the following resolution: make variables
private and provide protected access methods?
This should be done in both master and release branch. Also, document the
semantic versioning break for users.

~ Bhupesh


_______________________________________________________

Bhupesh Chawda

E: bhupesh@datatorrent.com | Twitter: @bhupeshsc

www.datatorrent.com  |  apex.apache.org



On Mon, May 15, 2017 at 11:40 AM, Vlad Rozov <v.rozov@datatorrent.com>
wrote:

> I am slightly in favor of getters and setters approach as well. Likely
> hotspot will optimize extra call anyway.
>
> Thank you,
> Vlad
>
> Отправлено с iPhone
>
> > On May 15, 2017, at 10:51, Bhupesh Chawda <bhupesh@datatorrent.com>
> wrote:
> >
> > I also suggest going for 1.
> > But I think we should make variables private and provide protected
> getters
> > and setters.
> >
> > ~ Bhupesh
> >
> >
> > On May 15, 2017 23:18, "Bhupesh Chawda" <bhupesh@datatorrent.com> wrote:
> >
> > Actually Ajay discovered this when upgrading the core dependency test.
> > One of the tests was failing.
> >
> > ~ Bhupesh
> >
> >
> > On May 15, 2017 23:15, "Pramod Immaneni" <pramod@datatorrent.com> wrote:
> >
> > I would suggest going with 1.
> >
> > Bhupesh how did you see this? Did it see it as part of working on an
> > operator in Malhar?
> >
> >> On Mon, May 15, 2017 at 9:53 AM, Vlad Rozov <v.rozov@datatorrent.com>
> wrote:
> >>
> >> Hi All,
> >>
> >> There is a possible change in operators behavior caused by changes that
> >> were introduced in the release 3.6.0 into DefaultInputPort and
> >> DefaultOutputPort. Please see https://issues.apache.org/jira
> >> /browse/APEXCORE-722. We need to agree how to proceed.
> >>
> >> 1. Break semantic versioning for the Default Input and Output Ports in
> the
> >> next release (3.7.0), declare protected variables as private and provide
> >> protected access method. Another option is to rename protected variables
> > to
> >> use less common names (for example __count).
> >> 2. Keep protected variables with the risk that the following common
> >> operator design pattern will be used accidentally by existing operators
> > and
> >> newly designed operators:
> >>
> >> public Operator extends BaseOperator {
> >>  private int count;
> >>  public DefaultInputPort in = new DefaultInputPort() {
> >>    @Override
> >>    public void process(Object tuple)
> >>    {
> >>       count++;  // updates DefaultInputPort count, not Operator count!
> >>    }
> >>  }
> >> }
> >>
> >>
> >> Thank you,
> >>
> >> Vlad
> >>
>

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