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? > > >
