flink-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephan Ewen <se...@apache.org>
Subject Re: [DISCUSS] Scala code style - explicit vs implicit code behavior
Date Wed, 18 Feb 2015 12:02:36 GMT
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 <parisc@kth.se> 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 <trohrmann@apache.org> wrote:
> >
> > +1
> >
> > On Mon, Feb 16, 2015 at 3:38 PM, Aljoscha Krettek <aljoscha@apache.org>
> > wrote:
> >
> >> +1
> >>
> >> On Mon, Feb 16, 2015 at 3:18 PM, Fabian Hueske <fhueske@gmail.com>
> wrote:
> >>> +1
> >>>
> >>> 2015-02-15 17:47 GMT+01:00 Stephan Ewen <sewen@apache.org>:
> >>>
> >>>> I thought about adding a wiki page for that.
> >>>>
> >>>> On Sat, Feb 14, 2015 at 7:16 PM, Henry Saputra <
> henry.saputra@gmail.com
> >>>
> >>>> 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 <sewen@apache.org>
> >> 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
> >>>>>>
> >>>>>
> >>>>
> >>
>
>

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