My initial mail had it listed, adding more details here since I assume I am missing something or not being clear - please note, this is just illustrative and my scala knowledge is bad :-) (I am trying to draw parallels from mistakes in java world)
def createFoo = new Foo() To def createFoo = new Foo1() To def createFoo = new Foo2() (appropriate inheritance applied - parent Foo). I am thinking from api evolution and binary compatibility point of view Regards, Mridul On Feb 20, 2014 12:12 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? > > > > >> > > > > > >> > > > > > > > > > >
