Difference between "def a()" a "def a"?

The ParamClauses construction (note plural) indicates that there should be zero or more ParamClause constructions (note singular) followed by an optional "implicit" parameter list. A def without round brackets would be constructed through a ParamClauses with zero instances of ParamClause and without the optional "implicit" parameter list.

(But you're right, there is an extra } at the end of the line.)

--j

On Fri, Mar 20, 2009 at 11:32 AM, Joachim Ansorg <nospam@joachim-ansorg.de> wrote:

Hi,
currently I'm looking at method declarations in Scala.
If I have the code

abstract class Test {
       def a : String
       def b() : String
}

Up to now I thought that I can override "def a" with "val a" but not "def
b()". The compiler does accept this code, though:

class MyTest extends Test {
       val a : String = "a"
       val b : String = "b"
}

So, what are methods without a parameter list for?

Thanks a lot,
Joachim

P.S.: As far as I can see the grammar in the language spec (section 4.6)
doesn't allow "def a" without the round brackets. Am I blind?

P.S: Am I right that there's curly bracket at the end of
       ParamClause ::=[nl] ‘(’ [Params] ‘)’}
which doesn't belong there? (in the language spec, section 4.6)

Jorge,
I see it now - thanks for pointing this out :)

So does this mean that there's no difference at all between "def a" and "def
a()" besides the syntax?

Regards,
Joachim

> The ParamClauses construction (note plural) indicates that there should be
> zero or more ParamClause constructions (note singular) followed by an
> optional "implicit" parameter list. A def without round brackets would be
> constructed through a ParamClauses with zero instances of ParamClause and
> without the optional "implicit" parameter list.
>
> (But you're right, there is an extra } at the end of the line.)

def a defines a method with no parameter lists.
def a() defines a method with 1 empty parameter list.

You can call def a as a
You can call def a() as a or a()

One convention (which I don't use; this is not a recommendation either
way) is to use def a(), and call it as a(), when a is not
referentially transparent.

2009/3/20 Joachim Ansorg :
> Jorge,
> I see it now -  thanks for pointing this out :)
>
> So does this mean that there's no difference at all between "def a" and "def
> a()"  besides the syntax?
>
> Regards,
> Joachim
>
>> The ParamClauses construction (note plural) indicates that there should be
>> zero or more ParamClause constructions (note singular) followed by an
>> optional "implicit" parameter list. A def without round brackets would be
>> constructed through a ParamClauses with zero instances of ParamClause and
>> without the optional "implicit" parameter list.
>>
>> (But you're right, there is an extra } at the end of the line.)
>
>
>

Ricky,
thanks for the clarification.

> def a defines a method with no parameter lists.
> def a() defines a method with 1 empty parameter list.
>
> You can call def a as a
> You can call def a() as a or a()

So "def a()" can do everything what "def a" can do? Isn't "def a" unnecessary
then?
"def a" looks more like a val or var, though.

I wanted to understand why "def a" was made possible in the language.

Joachim

On Fri, Mar 20, 2009 at 08:55:14PM +0100, Joachim Ansorg wrote:
> So "def a()" can do everything what "def a" can do? Isn't "def a"
> unnecessary then? "def a" looks more like a val or var, though.
>
> I wanted to understand why "def a" was made possible in the language.

I don't know what is the official reasoning, but there's at least this
situation where the no-parens form is likely to be preferred:

scala> def a1 = "abc".length _
a1: () => Int

scala> def a2() = "abc".length _
a2: ()() => Int

scala> a1
res9: () => Int =

scala> a1()
res10: Int = 3

scala> a2
res11: () => Int =

scala> a2()
res12: () => Int =

scala> a2()()
res13: Int = 3

I think def a is the "more idiomatic" way to write it.

The difference in invocation syntax between def a and def a() was blurred, such that using Java APIs was not a total pain (e.g., you can do javaList.size vs having to do javaList.size()).

That said, def a and def a() are not entirely identical, as you and other have noted.

Some people suggest using () only for methods that have side-effects.

I would suggest that, as a matter of style, Scala methods should always be invoked how they are defined (i.e., def a is invoked with a, def a() is invoked with a()).

--j

On Fri, Mar 20, 2009 at 12:55 PM, Joachim Ansorg <nospam@joachim-ansorg.de> wrote:

Ricky,
thanks for the clarification.

> def a defines a method with no parameter lists.
> def a() defines a method with 1 empty parameter list.
>
> You can call def a as a
> You can call def a() as a or a()

So "def a()" can do everything what "def a" can do?  Isn't "def a" unnecessary
then?
"def a" looks more like a val or var, though.

I wanted to understand why "def a" was made possible in the language.

Joachim

It'd be nice if Java setX could be called as foo.x = 5, and getX
called as .x too.

2009/3/20 Jorge Ortiz :
> I think def a is the "more idiomatic" way to write it.
>
> The difference in invocation syntax between def a and def a() was blurred,
> such that using Java APIs was not a total pain (e.g., you can do
> javaList.size vs having to do javaList.size()).
>
> That said, def a and def a() are not entirely identical, as you and other
> have noted.
>
> Some people suggest using () only for methods that have side-effects.
>
> I would suggest that, as a matter of style, Scala methods should always be
> invoked how they are defined (i.e., def a is invoked with a, def a() is
> invoked with a()).
>
> --j
>
> On Fri, Mar 20, 2009 at 12:55 PM, Joachim Ansorg
> wrote:
>>
>> Ricky,
>> thanks for the clarification.
>>
>> > def a defines a method with no parameter lists.
>> > def a() defines a method with 1 empty parameter list.
>> >
>> > You can call def a as a
>> > You can call def a() as a or a()
>>
>> So "def a()" can do everything what "def a" can do?  Isn't "def a"
>> unnecessary
>> then?
>> "def a" looks more like a val or var, though.
>>
>> I wanted to understand why "def a" was made possible in the language.
>>
>> Joachim
>
>

On Friday March 20 2009, Ricky Clarkson wrote:
> It'd be nice if Java setX could be called as foo.x = 5, and getX
> called as .x too.

I always refused to use that setBlah(...) getBlah() nonsense.
Overloading handles the distinction just fine in Java.

Randall Schulz

I'd guess you wouldn't get far in using Swing without calling getX and
setX methods.

2009/3/20 Randall R Schulz :
> On Friday March 20 2009, Ricky Clarkson wrote:
>> It'd be nice if Java setX could be called as foo.x = 5, and getX
>> called as .x too.
>
> I always refused to use that setBlah(...) getBlah() nonsense.
> Overloading handles the distinction just fine in Java.
>
>
> Randall Schulz
>

On Friday March 20 2009, Ricky Clarkson wrote:
> I'd guess you wouldn't get far in using Swing without calling getX
> and setX methods.

I didn't say I called methods as if they had different names than they
do. I said I don't name methods that I define that way.

RRS

No, you said: "I always refused to use that setBlah(...) getBlah() nonsense."

2009/3/20 Randall R Schulz :
> On Friday March 20 2009, Ricky Clarkson wrote:
>> I'd guess you wouldn't get far in using Swing without calling getX
>> and setX methods.
>
> I didn't say I called methods as if they had different names than they
> do. I said I don't name methods that I define that way.
>
>
> RRS
>

On Friday March 20 2009, Ricky Clarkson wrote:
> No, you said: "I always refused to use that setBlah(...) getBlah()
> nonsense."

Yes, I refuse to use it when choosing names. What else could it mean?

RRS

Joachim Ansorg-4 wrote:
>
> Hi,
> currently I'm looking at method declarations in Scala.
> If I have the code
>
> abstract class Test {
> def a : String
> def b() : String
> }
>
> Up to now I thought that I can override "def a" with "val a" but not "def
> b()". The compiler does accept this code, though:
>
> class MyTest extends Test {
> val a : String = "a"
> val b : String = "b"
> }
>
> So, what are methods without a parameter list for?
>
> Thanks a lot,
> Joachim
>
> P.S.: As far as I can see the grammar in the language spec (section 4.6)
> doesn't allow "def a" without the round brackets. Am I blind?
>
> P.S: Am I right that there's curly bracket at the end of
> ParamClause ::=[nl] ‘(’ [Params] ‘)’}
> which doesn't belong there? (in the language spec, section 4.6)
>
>
>

The idea of "blurring" the line between member variables and member
functions is a quite old idea and was explicitly formulated by Bertrand
Meyer as http://en.wikipedia.org/wiki/Uniform_access_principle Uniform
Access Principle .

> The idea of "blurring" the line between member variables and member
> functions is a quite old idea and was explicitly formulated
> by Bertrand
> Meyer as
> http://en.wikipedia.org/wiki/Uniform_access_principle Uniform
> Access Principle .

BTW: That whole topic seems very well covered in "Programming in Scala"
chapter 10.3: "Defining parameterless methods"

KR
Det

just a short remark on vocabulary:

Scala has chosen for methods with zero or more parameter lists.
Therefore I find it unnatural to talk about parameterless methods.

I would call def m = ...
 a parameterlistless method

and

I would call def m() = ...
 a one empty parameter list method
 [ abbreviation: an empty parameter list method,
   the 'one' being implicit ]

I agree, it does not matter to much,
but, as an instructor I've learned that
consistent vocabulary can be clarifying
[ and inconsistent vocabulary can be confusing ]

Much in the same way: is List[Int] a parameterized type?
I would call List[T] a parameterized type, and I
would call List[Int] a type that is obtained by
passing an Int type argument to the T type parameter.

again, there is no golden rule, consistency is what matters

[ if throughout a course, a computer is systematically called
  an umbrella, then that's fine for me ]

Luc


On Mon, Mar 23, 2009 at 9:34 AM, Detering Dirk <Dirk.Detering@bitmarck.de> wrote:

> The idea of "blurring" the line between member variables and member
> functions is a quite old idea and was explicitly formulated
> by Bertrand
> Meyer as
> http://en.wikipedia.org/wiki/Uniform_access_principle Uniform
> Access Principle .


BTW: That whole topic seems very well covered in "Programming in Scala"
chapter 10.3: "Defining parameterless methods"

KR
Det

--
  __~O
 -\ <,
(*)/ (*)

reality goes far beyond imagination

On Monday March 23 2009, Luc Duponcheel wrote:
> just a short remark on vocabulary:
>
> Scala has chosen for methods with zero or more parameter *lists*.
> Therefore I find it unnatural to talk about parameterless methods.
>
> I would call def m = ...
> a parameterlistless method

Maybe you could call them "listless" for short. But then you might
think they'd be unlikely to actually do what you request of them...

RRS

Can a method include an empty parameter list alongside other parameter lists?

On Mon, Mar 23, 2009 at 9:37 AM, Randall R Schulz <rschulz@sonic.net> wrote:

On Monday March 23 2009, Luc Duponcheel wrote:
> just a short remark on vocabulary:
>
> Scala has chosen for methods with zero or more parameter *lists*.
> Therefore I find it unnatural to talk about parameterless methods.
>
> I would call def m = ...
>  a parameterlistless method

Maybe you could call them  "listless" for short. But then you might
think they'd be unlikely to actually do what you request of them...


RRS

On Tue, Mar 24, 2009 at 5:54 AM, Naftoli Gugenheim wrote:
> Can a method include an empty parameter list alongside other parameter
> lists?

scala> def foo()(x: Int)() = x + 1
foo: ()(Int)()Int

scala> foo()(4)
res0: Int = 5

Stuart

Hello!
Somehow i thought this was related:
http://blogs.tedneward.com/2009/03/29/Laziness+In+Scala.aspx

It's not.  He's surprised by the difference between def a and val a, not by the difference between def a() and def a.

On Sun, Mar 29, 2009 at 2:47 PM, andreas s. <andreas_scheinert@web.de> wrote:

Hello!
Somehow i thought this was related:
http://blogs.tedneward.com/2009/03/29/Laziness+In+Scala.aspx
--
View this message in context: http://www.nabble.com/Difference-between-%22def-a%28%29%22-a-%22def-a%22--tp22626285p22773196.html
Sent from the Scala - User mailing list archive at Nabble.com.