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 <r...@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 <mri...@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 <r...@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?
> >
>

Reply via email to