Without bikeshedding this too much ... It is likely incorrect (not wrong) - and rules like this potentially cause things to slip through.
Explicit return type strictly specifies what is being exposed (think in face of impl change - createFoo changes in future from Foo to Foo1 or Foo2) .. being conservative about how to specify exposed interfaces, imo, outweighs potential gains in breveity of code. Btw this is a degenerate contrieved example already stretching its use ... Regards Mridul Regards Mridul On Feb 19, 2014 1:49 PM, "Reynold Xin" <r...@databricks.com> wrote: > 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? > > >> > > > >> > > >
