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 <bhup...@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" <bhup...@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" <pra...@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.ro...@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 >>
