I found Haskell's convention of including type signatures as documentation to be worthwhile.
http://www.haskell.org/haskellwiki/Type_signatures_as_good_style I'd support a guideline to include type signatures where they're unclear but would prefer to leave it quite vague. In my experience, the lightest process is the best process for contributions. Strict rules here _will_ drive away contributors. On Wed, Feb 19, 2014 at 10:42 AM, Reynold Xin <r...@databricks.com> wrote: > 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? > > > > >> > > > > > >> > > > > > > > > > >
