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 <c...@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 <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? >> > >>
