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 <par...@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 <trohrm...@apache.org> wrote: > > > > +1 > > > > On Mon, Feb 16, 2015 at 3:38 PM, Aljoscha Krettek <aljos...@apache.org> > > wrote: > > > >> +1 > >> > >> On Mon, Feb 16, 2015 at 3:18 PM, Fabian Hueske <fhue...@gmail.com> > wrote: > >>> +1 > >>> > >>> 2015-02-15 17:47 GMT+01:00 Stephan Ewen <se...@apache.org>: > >>> > >>>> I thought about adding a wiki page for that. > >>>> > >>>> On Sat, Feb 14, 2015 at 7:16 PM, Henry Saputra < > henry.sapu...@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 <se...@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 > >>>>>> > >>>>> > >>>> > >> > >
