[DISCUSS] Scala code style - explicit vs implicit code behavior

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

[DISCUSS] Scala code style - explicit vs implicit code behavior

Stephan Ewen
Hi everyone!

Since a sizable portion of the Flink code is now in Scala (and more is
coming in the API projects), I think we need to define a few guidelines for
Scala programming.

Scala is very powerful and has a lot of "magic" features that allow you to
design killer nice APIs, but also make reasoning about code harder.
Through the use of implicit parameters, lazy parameters, overriding of base
operators, functions that take code blocks, etc, you can easily write code
that does something entirely different than what it looks like initially.

For APIs, I think we should embrace the power of these features to make the
APIs nice, convenient, and with intuitive syntax. After all, the elegance
of the API matters a lot.

For the runtime or anything below the APIs, I propose to refrain to a large
extend from the magic features. For those parts, I think it matters most
that the code is predictable, it is easy to understand the implications for
also non-expert Scala programmers, and it is possible to peer review it
through GitHub (where you do not see a difference between a lazy or an
eager parameter).

One example of such a change would be
https://issues.apache.org/jira/browse/FLINK-1548

Summary: Be magic in the APIs, be explicit and simple in the runtime.

Greetings,
Stephan
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Scala code style - explicit vs implicit code behavior

Henry Saputra
+1 to the idea

I suppose no really action item for FLINK-1548? Maybe add doc about
contributing to Scala portion?


On Saturday, February 14, 2015, Stephan Ewen <[hidden email]> wrote:

> Hi everyone!
>
> Since a sizable portion of the Flink code is now in Scala (and more is
> coming in the API projects), I think we need to define a few guidelines for
> Scala programming.
>
> Scala is very powerful and has a lot of "magic" features that allow you to
> design killer nice APIs, but also make reasoning about code harder.
> Through the use of implicit parameters, lazy parameters, overriding of base
> operators, functions that take code blocks, etc, you can easily write code
> that does something entirely different than what it looks like initially.
>
> For APIs, I think we should embrace the power of these features to make the
> APIs nice, convenient, and with intuitive syntax. After all, the elegance
> of the API matters a lot.
>
> For the runtime or anything below the APIs, I propose to refrain to a large
> extend from the magic features. For those parts, I think it matters most
> that the code is predictable, it is easy to understand the implications for
> also non-expert Scala programmers, and it is possible to peer review it
> through GitHub (where you do not see a difference between a lazy or an
> eager parameter).
>
> One example of such a change would be
> https://issues.apache.org/jira/browse/FLINK-1548
>
> Summary: Be magic in the APIs, be explicit and simple in the runtime.
>
> Greetings,
> Stephan
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Scala code style - explicit vs implicit code behavior

Stephan Ewen
I thought about adding a wiki page for that.

On Sat, Feb 14, 2015 at 7:16 PM, Henry Saputra <[hidden email]>
wrote:

> +1 to the idea
>
> I suppose no really action item for FLINK-1548? Maybe add doc about
> contributing to Scala portion?
>
>
> On Saturday, February 14, 2015, Stephan Ewen <[hidden email]> wrote:
>
> > Hi everyone!
> >
> > Since a sizable portion of the Flink code is now in Scala (and more is
> > coming in the API projects), I think we need to define a few guidelines
> for
> > Scala programming.
> >
> > Scala is very powerful and has a lot of "magic" features that allow you
> to
> > design killer nice APIs, but also make reasoning about code harder.
> > Through the use of implicit parameters, lazy parameters, overriding of
> base
> > operators, functions that take code blocks, etc, you can easily write
> code
> > that does something entirely different than what it looks like initially.
> >
> > For APIs, I think we should embrace the power of these features to make
> the
> > APIs nice, convenient, and with intuitive syntax. After all, the elegance
> > of the API matters a lot.
> >
> > For the runtime or anything below the APIs, I propose to refrain to a
> large
> > extend from the magic features. For those parts, I think it matters most
> > that the code is predictable, it is easy to understand the implications
> for
> > also non-expert Scala programmers, and it is possible to peer review it
> > through GitHub (where you do not see a difference between a lazy or an
> > eager parameter).
> >
> > One example of such a change would be
> > https://issues.apache.org/jira/browse/FLINK-1548
> >
> > Summary: Be magic in the APIs, be explicit and simple in the runtime.
> >
> > Greetings,
> > Stephan
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Scala code style - explicit vs implicit code behavior

Fabian Hueske-2
+1

2015-02-15 17:47 GMT+01:00 Stephan Ewen <[hidden email]>:

> I thought about adding a wiki page for that.
>
> On Sat, Feb 14, 2015 at 7:16 PM, Henry Saputra <[hidden email]>
> wrote:
>
> > +1 to the idea
> >
> > I suppose no really action item for FLINK-1548? Maybe add doc about
> > contributing to Scala portion?
> >
> >
> > On Saturday, February 14, 2015, Stephan Ewen <[hidden email]> wrote:
> >
> > > Hi everyone!
> > >
> > > Since a sizable portion of the Flink code is now in Scala (and more is
> > > coming in the API projects), I think we need to define a few guidelines
> > for
> > > Scala programming.
> > >
> > > Scala is very powerful and has a lot of "magic" features that allow you
> > to
> > > design killer nice APIs, but also make reasoning about code harder.
> > > Through the use of implicit parameters, lazy parameters, overriding of
> > base
> > > operators, functions that take code blocks, etc, you can easily write
> > code
> > > that does something entirely different than what it looks like
> initially.
> > >
> > > For APIs, I think we should embrace the power of these features to make
> > the
> > > APIs nice, convenient, and with intuitive syntax. After all, the
> elegance
> > > of the API matters a lot.
> > >
> > > For the runtime or anything below the APIs, I propose to refrain to a
> > large
> > > extend from the magic features. For those parts, I think it matters
> most
> > > that the code is predictable, it is easy to understand the implications
> > for
> > > also non-expert Scala programmers, and it is possible to peer review it
> > > through GitHub (where you do not see a difference between a lazy or an
> > > eager parameter).
> > >
> > > One example of such a change would be
> > > https://issues.apache.org/jira/browse/FLINK-1548
> > >
> > > Summary: Be magic in the APIs, be explicit and simple in the runtime.
> > >
> > > Greetings,
> > > Stephan
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Scala code style - explicit vs implicit code behavior

Aljoscha Krettek-2
+1

On Mon, Feb 16, 2015 at 3:18 PM, Fabian Hueske <[hidden email]> wrote:

> +1
>
> 2015-02-15 17:47 GMT+01:00 Stephan Ewen <[hidden email]>:
>
>> I thought about adding a wiki page for that.
>>
>> On Sat, Feb 14, 2015 at 7:16 PM, Henry Saputra <[hidden email]>
>> wrote:
>>
>> > +1 to the idea
>> >
>> > I suppose no really action item for FLINK-1548? Maybe add doc about
>> > contributing to Scala portion?
>> >
>> >
>> > On Saturday, February 14, 2015, Stephan Ewen <[hidden email]> wrote:
>> >
>> > > Hi everyone!
>> > >
>> > > Since a sizable portion of the Flink code is now in Scala (and more is
>> > > coming in the API projects), I think we need to define a few guidelines
>> > for
>> > > Scala programming.
>> > >
>> > > Scala is very powerful and has a lot of "magic" features that allow you
>> > to
>> > > design killer nice APIs, but also make reasoning about code harder.
>> > > Through the use of implicit parameters, lazy parameters, overriding of
>> > base
>> > > operators, functions that take code blocks, etc, you can easily write
>> > code
>> > > that does something entirely different than what it looks like
>> initially.
>> > >
>> > > For APIs, I think we should embrace the power of these features to make
>> > the
>> > > APIs nice, convenient, and with intuitive syntax. After all, the
>> elegance
>> > > of the API matters a lot.
>> > >
>> > > For the runtime or anything below the APIs, I propose to refrain to a
>> > large
>> > > extend from the magic features. For those parts, I think it matters
>> most
>> > > that the code is predictable, it is easy to understand the implications
>> > for
>> > > also non-expert Scala programmers, and it is possible to peer review it
>> > > through GitHub (where you do not see a difference between a lazy or an
>> > > eager parameter).
>> > >
>> > > One example of such a change would be
>> > > https://issues.apache.org/jira/browse/FLINK-1548
>> > >
>> > > Summary: Be magic in the APIs, be explicit and simple in the runtime.
>> > >
>> > > Greetings,
>> > > Stephan
>> > >
>> >
>>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Scala code style - explicit vs implicit code behavior

Till Rohrmann
+1

On Mon, Feb 16, 2015 at 3:38 PM, Aljoscha Krettek <[hidden email]>
wrote:

> +1
>
> On Mon, Feb 16, 2015 at 3:18 PM, Fabian Hueske <[hidden email]> wrote:
> > +1
> >
> > 2015-02-15 17:47 GMT+01:00 Stephan Ewen <[hidden email]>:
> >
> >> I thought about adding a wiki page for that.
> >>
> >> On Sat, Feb 14, 2015 at 7:16 PM, Henry Saputra <[hidden email]
> >
> >> wrote:
> >>
> >> > +1 to the idea
> >> >
> >> > I suppose no really action item for FLINK-1548? Maybe add doc about
> >> > contributing to Scala portion?
> >> >
> >> >
> >> > On Saturday, February 14, 2015, Stephan Ewen <[hidden email]>
> wrote:
> >> >
> >> > > Hi everyone!
> >> > >
> >> > > Since a sizable portion of the Flink code is now in Scala (and more
> is
> >> > > coming in the API projects), I think we need to define a few
> guidelines
> >> > for
> >> > > Scala programming.
> >> > >
> >> > > Scala is very powerful and has a lot of "magic" features that allow
> you
> >> > to
> >> > > design killer nice APIs, but also make reasoning about code harder.
> >> > > Through the use of implicit parameters, lazy parameters, overriding
> of
> >> > base
> >> > > operators, functions that take code blocks, etc, you can easily
> write
> >> > code
> >> > > that does something entirely different than what it looks like
> >> initially.
> >> > >
> >> > > For APIs, I think we should embrace the power of these features to
> make
> >> > the
> >> > > APIs nice, convenient, and with intuitive syntax. After all, the
> >> elegance
> >> > > of the API matters a lot.
> >> > >
> >> > > For the runtime or anything below the APIs, I propose to refrain to
> a
> >> > large
> >> > > extend from the magic features. For those parts, I think it matters
> >> most
> >> > > that the code is predictable, it is easy to understand the
> implications
> >> > for
> >> > > also non-expert Scala programmers, and it is possible to peer
> review it
> >> > > through GitHub (where you do not see a difference between a lazy or
> an
> >> > > eager parameter).
> >> > >
> >> > > One example of such a change would be
> >> > > https://issues.apache.org/jira/browse/FLINK-1548
> >> > >
> >> > > Summary: Be magic in the APIs, be explicit and simple in the
> runtime.
> >> > >
> >> > > Greetings,
> >> > > Stephan
> >> > >
> >> >
> >>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Scala code style - explicit vs implicit code behavior

Paris Carbone
+1

Good point. In general, keeping the common/runtime as simple as possible is quite important

> On 16 Feb 2015, at 16:05, Till Rohrmann <[hidden email]> wrote:
>
> +1
>
> On Mon, Feb 16, 2015 at 3:38 PM, Aljoscha Krettek <[hidden email]>
> wrote:
>
>> +1
>>
>> On Mon, Feb 16, 2015 at 3:18 PM, Fabian Hueske <[hidden email]> wrote:
>>> +1
>>>
>>> 2015-02-15 17:47 GMT+01:00 Stephan Ewen <[hidden email]>:
>>>
>>>> I thought about adding a wiki page for that.
>>>>
>>>> On Sat, Feb 14, 2015 at 7:16 PM, Henry Saputra <[hidden email]
>>>
>>>> wrote:
>>>>
>>>>> +1 to the idea
>>>>>
>>>>> I suppose no really action item for FLINK-1548? Maybe add doc about
>>>>> contributing to Scala portion?
>>>>>
>>>>>
>>>>> On Saturday, February 14, 2015, Stephan Ewen <[hidden email]>
>> wrote:
>>>>>
>>>>>> Hi everyone!
>>>>>>
>>>>>> Since a sizable portion of the Flink code is now in Scala (and more
>> is
>>>>>> coming in the API projects), I think we need to define a few
>> guidelines
>>>>> for
>>>>>> Scala programming.
>>>>>>
>>>>>> Scala is very powerful and has a lot of "magic" features that allow
>> you
>>>>> to
>>>>>> design killer nice APIs, but also make reasoning about code harder.
>>>>>> Through the use of implicit parameters, lazy parameters, overriding
>> of
>>>>> base
>>>>>> operators, functions that take code blocks, etc, you can easily
>> write
>>>>> code
>>>>>> that does something entirely different than what it looks like
>>>> initially.
>>>>>>
>>>>>> For APIs, I think we should embrace the power of these features to
>> make
>>>>> the
>>>>>> APIs nice, convenient, and with intuitive syntax. After all, the
>>>> elegance
>>>>>> of the API matters a lot.
>>>>>>
>>>>>> For the runtime or anything below the APIs, I propose to refrain to
>> a
>>>>> large
>>>>>> extend from the magic features. For those parts, I think it matters
>>>> most
>>>>>> that the code is predictable, it is easy to understand the
>> implications
>>>>> for
>>>>>> also non-expert Scala programmers, and it is possible to peer
>> review it
>>>>>> through GitHub (where you do not see a difference between a lazy or
>> an
>>>>>> eager parameter).
>>>>>>
>>>>>> One example of such a change would be
>>>>>> https://issues.apache.org/jira/browse/FLINK-1548
>>>>>>
>>>>>> Summary: Be magic in the APIs, be explicit and simple in the
>> runtime.
>>>>>>
>>>>>> Greetings,
>>>>>> Stephan
>>>>>>
>>>>>
>>>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Scala code style - explicit vs implicit code behavior

Stephan Ewen
Moved this to the Wiki:
https://cwiki.apache.org/confluence/display/FLINK/Coding+Guidelines+for+Scala

On Mon, Feb 16, 2015 at 4:29 PM, Paris Carbone <[hidden email]> wrote:

> +1
>
> Good point. In general, keeping the common/runtime as simple as possible
> is quite important
>
> > On 16 Feb 2015, at 16:05, Till Rohrmann <[hidden email]> wrote:
> >
> > +1
> >
> > On Mon, Feb 16, 2015 at 3:38 PM, Aljoscha Krettek <[hidden email]>
> > wrote:
> >
> >> +1
> >>
> >> On Mon, Feb 16, 2015 at 3:18 PM, Fabian Hueske <[hidden email]>
> wrote:
> >>> +1
> >>>
> >>> 2015-02-15 17:47 GMT+01:00 Stephan Ewen <[hidden email]>:
> >>>
> >>>> I thought about adding a wiki page for that.
> >>>>
> >>>> On Sat, Feb 14, 2015 at 7:16 PM, Henry Saputra <
> [hidden email]
> >>>
> >>>> wrote:
> >>>>
> >>>>> +1 to the idea
> >>>>>
> >>>>> I suppose no really action item for FLINK-1548? Maybe add doc about
> >>>>> contributing to Scala portion?
> >>>>>
> >>>>>
> >>>>> On Saturday, February 14, 2015, Stephan Ewen <[hidden email]>
> >> wrote:
> >>>>>
> >>>>>> Hi everyone!
> >>>>>>
> >>>>>> Since a sizable portion of the Flink code is now in Scala (and more
> >> is
> >>>>>> coming in the API projects), I think we need to define a few
> >> guidelines
> >>>>> for
> >>>>>> Scala programming.
> >>>>>>
> >>>>>> Scala is very powerful and has a lot of "magic" features that allow
> >> you
> >>>>> to
> >>>>>> design killer nice APIs, but also make reasoning about code harder.
> >>>>>> Through the use of implicit parameters, lazy parameters, overriding
> >> of
> >>>>> base
> >>>>>> operators, functions that take code blocks, etc, you can easily
> >> write
> >>>>> code
> >>>>>> that does something entirely different than what it looks like
> >>>> initially.
> >>>>>>
> >>>>>> For APIs, I think we should embrace the power of these features to
> >> make
> >>>>> the
> >>>>>> APIs nice, convenient, and with intuitive syntax. After all, the
> >>>> elegance
> >>>>>> of the API matters a lot.
> >>>>>>
> >>>>>> For the runtime or anything below the APIs, I propose to refrain to
> >> a
> >>>>> large
> >>>>>> extend from the magic features. For those parts, I think it matters
> >>>> most
> >>>>>> that the code is predictable, it is easy to understand the
> >> implications
> >>>>> for
> >>>>>> also non-expert Scala programmers, and it is possible to peer
> >> review it
> >>>>>> through GitHub (where you do not see a difference between a lazy or
> >> an
> >>>>>> eager parameter).
> >>>>>>
> >>>>>> One example of such a change would be
> >>>>>> https://issues.apache.org/jira/browse/FLINK-1548
> >>>>>>
> >>>>>> Summary: Be magic in the APIs, be explicit and simple in the
> >> runtime.
> >>>>>>
> >>>>>> Greetings,
> >>>>>> Stephan
> >>>>>>
> >>>>>
> >>>>
> >>
>
>