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 <se...@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.sapu...@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.sapu...@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 > > > > > >
