flink-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Till Rohrmann <trohrm...@apache.org>
Subject Re: [DISCUSS] Scala code style - explicit vs implicit code behavior
Date Mon, 16 Feb 2015 15:05:42 GMT
+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