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?
