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