I agree, makes sense. Please note I was referring only to exposed user api in my comments - not other code !
Regards, Mridul On Feb 20, 2014 12:15 AM, "Andrew Ash" <and...@andrewash.com> wrote: > 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? > > > > > >> > > > > > > >> > > > > > > > > > > > > > > >
