spark-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reynold Xin <r...@databricks.com>
Subject Re: coding style discussion: explicit return type in public APIs
Date Wed, 19 Feb 2014 08:19:18 GMT
Yes, the case you brought up is not a matter of readability or style. If it
returns a different type, it should be declared (otherwise it is just
wrong).


On Wed, Feb 19, 2014 at 12:17 AM, Mridul Muralidharan <mridul@gmail.com>wrote:

> You are right.
> A degenerate case would be :
>
> def createFoo = new FooImpl()
>
> vs
>
> def createFoo: Foo = new FooImpl()
>
> Former will cause api instability. Reynold, maybe this is already
> avoided - and I understood it wrong ?
>
> Thanks,
> Mridul
>
>
>
> On Wed, Feb 19, 2014 at 12:44 PM, Christopher Nguyen <ctn@adatao.com>
> wrote:
> > Mridul, IIUUC, what you've mentioned did come to mind, but I deemed it
> > orthogonal to the stylistic issue Reynold is talking about.
> >
> > I believe you're referring to the case where there is a specific desired
> > return type by API design, but the implementation does not, in which
> case,
> > of course, one must define the return type. That's an API requirement and
> > not just a matter of readability.
> >
> > We could add this as an NB in the proposed guideline.
> >
> > --
> > Christopher T. Nguyen
> > Co-founder & CEO, Adatao <http://adatao.com>
> > linkedin.com/in/ctnguyen
> >
> >
> >
> > On Tue, Feb 18, 2014 at 10:40 PM, Reynold Xin <rxin@databricks.com>
> wrote:
> >
> >> +1 Christopher's suggestion.
> >>
> >> Mridul,
> >>
> >> How would that happen? Case 3 requires the method to be invoking the
> >> constructor directly. It was implicit in my email, but the return type
> >> should be the same as the class itself.
> >>
> >>
> >>
> >>
> >> On Tue, Feb 18, 2014 at 10:37 PM, Mridul Muralidharan <mridul@gmail.com
> >> >wrote:
> >>
> >> > Case 3 can be a potential issue.
> >> > Current implementation might be returning a concrete class which we
> >> > might want to change later - making it a type change.
> >> > The intention might be to return an RDD (for example), but the
> >> > inferred type might be a subclass of RDD - and future changes will
> >> > cause signature change.
> >> >
> >> >
> >> > Regards,
> >> > Mridul
> >> >
> >> >
> >> > On Wed, Feb 19, 2014 at 11:52 AM, Reynold Xin <rxin@databricks.com>
> >> wrote:
> >> > > Hi guys,
> >> > >
> >> > > Want to bring to the table this issue to see what other members of
> the
> >> > > community think and then we can codify it in the Spark coding style
> >> > guide.
> >> > > The topic is about declaring return types explicitly in public APIs.
> >> > >
> >> > > In general I think we should favor explicit type declaration in
> public
> >> > > APIs. However, I do think there are 3 cases we can avoid the public
> API
> >> > > definition because in these 3 cases the types are self-evident &
> >> > repetitive.
> >> > >
> >> > > Case 1. toString
> >> > >
> >> > > Case 2. A method returning a string or a val defining a string
> >> > >
> >> > > def name = "abcd" // this is so obvious that it is a string
> >> > > val name = "edfg" // this too
> >> > >
> >> > > Case 3. The method or variable is invoking the constructor of a
> class
> >> and
> >> > > return that immediately. For example:
> >> > >
> >> > > val a = new SparkContext(...)
> >> > > implicit def rddToAsyncRDDActions[T: ClassTag](rdd: RDD[T]) = new
> >> > > AsyncRDDActions(rdd)
> >> > >
> >> > >
> >> > > Thoughts?
> >> >
> >>
>

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