Yes, the case you brought up is not a matter of readability or style. If it returns a different type, it should be declared (otherwise it is just wrong).
On Wed, Feb 19, 2014 at 12:17 AM, Mridul Muralidharan <mri...@gmail.com>wrote: > 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? > >> > > >> >
