Mailing-List: contact dev-help@apex.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@apex.apache.org
MIME-Version: 1.0
In-Reply-To: <b38e1655-a396-bf22-76c2-ab673597d7c5@datatorrent.com>
References: <b38e1655-a396-bf22-76c2-ab673597d7c5@datatorrent.com>
From: Sanjay Pujare <sanjay@datatorrent.com>
Date: Mon, 15 May 2017 10:06:50 -0700
Message-ID: <CALPtS-KuFek20518p-gKRSCB_26xKdOGP1u2k-w115Yd4NkuzQ@mail.gmail.com>
Subject: Re: Backward compatibility issue in 3.6.0 release
To: dev@apex.apache.org
Content-Type: multipart/alternative; boundary="001a113cea64c938d3054f9314b6"
archived-at: Mon, 15 May 2017 17:07:04 -0000

--001a113cea64c938d3054f9314b6
Content-Type: text/plain; charset="UTF-8"

I vote for renaming to less common names like __count. The renaming breaks
compatibility from 3.6.0 to 3.7.0 but seems to be the best option.

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
>

--001a113cea64c938d3054f9314b6--