Mridul, Can you be more specific in the createFoo example?
def myFunc = createFoo is disallowed in my guideline. It is invoking a function createFoo, not the constructor of Foo. On Wed, Feb 19, 2014 at 10:39 AM, Mridul Muralidharan <mri...@gmail.com>wrote: > 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? > > > >> > > > > >> > > > > > >
