flink-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kostas Tzoumas <ktzou...@apache.org>
Subject Re: [DISCUSS] Discourage using the same class names even though in different packages
Date Tue, 24 Feb 2015 08:55:16 GMT
I agree, at least for all non-user facing classes (e.g., the examples in
Scala/Java/Streaming etc may have the same names)

Kostas

On Tue, Feb 24, 2015 at 9:10 AM, Stephan Ewen <sewen@apache.org> wrote:

> That is a good comment, Henry.
>
> Let's try and follow this rule...
> Am 24.02.2015 02:28 schrieb "Henry Saputra" <henry.saputra@gmail.com>:
>
> > Just to be clear that I was not advocating flink to simplify the code
> > just for the sake of clarity :)
> >
> > Flink has a lot to offer by providing simple APIs by hiding complexity to
> > achieve performance. Which I think is one of the key differentiator
> compare
> > to other general distributed processing platform.
> >
> > My suggestion was meant to help contributors and committers to
> > easily follow and keep up with changes that impact kernel or gut of
> Flink.
> >
> > Thoughts and comments are welcomed :)
> >
> > On Monday, February 23, 2015, Henry Saputra <henry.saputra@gmail.com>
> > wrote:
> >
> > > Hi All,
> > >
> > > I am seeing some same class names, even though in different package
> > > names, that could confuse new contributors. One of the attractiveness
> > > of Spark that it is the code structure is simple to follow than Hadoop
> > > (or Hive for that matter).
> > >
> > > For example we have IntermediateResultPartition in both partition and
> > > executiongraph packages, which both are under runtime parent package.
> > > To make it more difficult, some of these duplicate classes have no
> > > Javadoc or comment why the class exist and how does it relates to
> > > other existing code, one has to trace the code and figure out where
> > > the code is used and how it is impacting or differ the others existing
> > > classes.
> > >
> > > I  would like to propose the "no duplicate class name if possible"
> > > (which I know is possible) in the how to contribute code guide.
> > >
> > > - Henry
> > >
> >
>

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