Question on the '=' sign and 'Unit' return type in a method definition

On 16/12/2010 10:03, xi developer wrote:
> If I have a method definition like the following:
>
> def click( )={ ... }
>
> I have two questions regards to this 'click' method.
>
> Q1. If the 'click' method has no argument and return Unit, can I define it also as 'def
> click{}', is the '=' optional? When does the '=' sign compulsory?
> Q2. When should I explicitly declare the return type of the method is 'Unit', and when I
> don't need to do so? For example, this 'click' method, it seems I don't need to indicate
> return type is 'Unit', but when I need to indicate this return type, and how? "def click(
> ) => Unit = {...}" or "def click( ) => Unit {...}", which is correct?

Some answers can be found in the Style Guide, which is a recommended reading as it shows
what is seen by many as "best practice".

Basically, you have three ways to write Unit methods:

object Fooo
{
def f1 { println("f1"); }
def f2() { println("f2"); }
// def f3(): Unit { println("f3"); }
def f3(): Unit = { println("f3"); }

def main(args: Array[String]) =
{
f1 // Defined without parentheses, must be called without
f2()
f3()
}
}

The first one is discouraged, as calling a method with side-effects without parameters
without parentheses is frown upon (ie. it should be used only for pure functional methods).

The third one is the most explicit but is seen as a bit verbose.

So the second one is recommended. Basically, the definition looks like a Java method
definition. This style of declaration is advised for Unit methods (ie. with side-effects).

Hi,

xi developer wrote:
> If I have a method definition like the following:
>
> def click( )={ ... }
>
> I have two questions regards to this 'click' method.
>
> Q1. If the 'click' method has no argument and return Unit, can I define
> it also as 'def click{}', is the '=' optional? When does the '=' sign
> compulsory?

If you omit the '=', then the return type is Unit, so if you want your method to return
anything interesting, then you should include the '='.

I don't think omitting the '=' is good practice though. (And I thought that I recalled it
was being deprecated from the language.) Given that '=' implies the return type will be
Unit, if you get into the habit of omitting it, you can easily accidentally omit it when you
/did/ want to return something, and waste time wondering why your method body is returning a
Unit. I speak from personal experience more than reams of empirical evidence.

> Q2. When should I explicitly declare the return type of the method is
> 'Unit', and when I don't need to do so? For example, this 'click'
> method, it seems I don't need to indicate return type is 'Unit', but
> when I need to indicate this return type, and how? "def click( ) => Unit
> = {...}" or "def click( ) => Unit {...}", which is correct?

Neither! You want to use ":" to indicate the type of something.

def click() : Unit = { .... }

and

def click() { .... }

compile to exactly the same thing.

You can also just write

def click() = { .... }

most of the time because the compiler will infer the type. Even if it infers the type as
something other than Unit, it probably doesn't matter hugely (apart from maybe being
potentially misleading) because you'll be using the method as a Unit at the call site.

Cheers,
Jon

On 16 December 2010 12:26, Jon Pretty <_@scala.propensive.com> wrote:

Hi,

xi developer wrote:
> If I have a method definition like the following:
>
> def click( )={ ... }
>
> I have two questions regards to this 'click' method.
>
> Q1. If the 'click' method has no argument and return Unit, can I define
> it also as 'def click{}', is the '=' optional? When does the '=' sign
> compulsory?

If you omit the '=', then the return type is Unit, so if you want your method to return
anything interesting, then you should include the '='.

I don't think omitting the '=' is good practice though.  (And I thought that I recalled it
was being deprecated from the language.)  Given that '=' implies the return type will be
Unit, if you get into the habit of omitting it, you can easily accidentally omit it when you
/did/ want to return something, and waste time wondering why your method body is returning a
Unit.  I speak from personal experience more than reams of empirical evidence.

I have to agree with Jon here, the = should never be omitted.  If nothing else, it'll be much easier in the future to implement this check in a tool like FindBugs.  A compiler plugin to enforce deprecation of the syntax would also be easier to write.

--
Kevin Wright

gtalk / msn : kev.lee.wright@gmail.comkev.lee.wright@gmail.commail: kevin.wright@scalatechnology.com
vibe / skype: kev.lee.wright
twitter: @thecoda

Am Donnerstag, 16. Dezember 2010, 10:03:25 schrieb xi developer:
> If I have a method definition like the following:
>
> def click( )={ ... }
>
> I have two questions regards to this 'click' method.
>
> Q1. If the 'click' method has no argument and return Unit, can I define it
> also as 'def click{}', is the '=' optional? When does the '=' sign
> compulsory?
> Q2. When should I explicitly declare the return type of the method is
> 'Unit', and when I don't need to do so? For example, this 'click' method,
> it seems I don't need to indicate return type is 'Unit', but when I need
> to indicate this return type, and how? "def click( ) => Unit = {...}" or
> "def click( ) => Unit {...}", which is correct?

My preposters already explained all the technical & style-stuff.

Just an experience note of mine:
I tend to explicitly state the return type of a function (except for very
simple cases - but this is subjective anyway).

It helps me to see immediately which type to expect when I call the function
(and I seldomly use IDEs to help me out) and it provides immediate feedback if
I mess up the function body and return something unintended.

[ok - you can easily catch me with: if you can't see the return type
immediately your function is too complex or verbose - go refactoring :-) ]

Greetings
Bernd

On Thu, Dec 16, 2010 at 4:26 AM, Jon Pretty <_@scala.propensive.com> wrote:

Hi,

xi developer wrote:
> If I have a method definition like the following:
>
> def click( )={ ... }
>
> I have two questions regards to this 'click' method.
>
> Q1. If the 'click' method has no argument and return Unit, can I define
> it also as 'def click{}', is the '=' optional? When does the '=' sign
> compulsory?

If you omit the '=', then the return type is Unit, so if you want your method to return
anything interesting, then you should include the '='.

I don't think omitting the '=' is good practice though.  (And I thought that I recalled it
was being deprecated from the language.)  Given that '=' implies the return type will be
Unit, if you get into the habit of omitting it, you can easily accidentally omit it when you
/did/ want to return something, and waste time wondering why your method body is returning a
Unit.  I speak from personal experience more than reams of empirical evidence.

I don't see the point of explicitly returning "Unit." It just looks unnatural to me. I would be surprised if omitting = is being deprecated. Yes, I've been bitten by forgetting to use = and getting Unit by default when I should have had some other type, but I don't see how requiring an explicit declaration of Unit helps if the return type can be inferred anyway (if you use =). If a function or method really does not return anything useful, then why should I have to declare the return type?

On a side note, I've always wondered why the term "Unit" is used to represent essentially "Nothing" or "None".

Russ P.

--
http://RussP.us

On 16/12/2010 21:04, Bernd Johannes wrote:
> I tend to explicitly state the return type of a function (except for very
> simple cases - but this is subjective anyway).
>
> It helps me to see immediately which type to expect when I call the function
> (and I seldomly use IDEs to help me out) and it provides immediate feedback if
> I mess up the function body and return something unintended.
>
> [ok - you can easily catch me with: if you can't see the return type
> immediately your function is too complex or verbose - go refactoring :-) ]

I agree. Type inference is nice, but somehow specifying explicitly the
type is:
- Helpful for those going after you, particularly if they are not Scala
experts (eg.: me);
- Part of the (auto)doc;
- A safe net: if the compiler disagree with you, you have to wonder what
is wrong with your code! (But of course, you can see the problem when
trying to use the function itself, too.)

In Scala, I omit the type for Unit, as recommended, since it has (can
have) a specific, unambiguous syntax (no =, which is logical since
nothing is returned).

2010/12/16 Russ Paielli <russ.paielli@gmail.com>

On a side note, I've always wondered why the term "Unit" is used to represent essentially "Nothing" or "None".

It is not. These are very different beasts.

For example, a function that returns Unit may return control to the caller. A function that returns Nothing never returns control to the caller or must throw an exception. None is a subtype of Option and has another meaning.

Also in the case of collections, a List[Unit] is not the same thing as a List[Nothing].

Cheers,
Sébastien

On 16 Dec 2010 23:14, "Sébastien Bocq" <sebastien.bocq@gmail.com> wrote:
>
>
> 2010/12/16 Russ Paielli <russ.paielli@gmail.com>
>
>>
>> On a side note, I've always wondered why the term "Unit" is used to represent essentially "Nothing" or "None".
>
>
> It is not. These are very different beasts.
>
> For example, a function that returns Unit may return control to the caller. A function that returns Nothing never returns control to the caller or must throw an exception. None is a subtype of Option and has another meaning.
>
> Also in the case of collections, a List[Unit] is not the same thing as a List[Nothing].
>
> Cheers,
> Sébastien

It's hard to imagine where you would return None,  that's like guaranteeing you'll return null - so pretty pointless.

Returning Nothing is the bottom type.  It subclasses everything, so you can happily call any method you want on it, knowing full well that control flow will never reach that far.  As in a method that always throws an exception - you can use the return value however you like.

Unit is like void: it returns, but not with a useable value.

Sorry, but I was just thinking in terms of Python, where a function that does not explicitly return anything returns "None" by default. I realize that "None" in Python is not quite the same idea as "None" in Scala, but I wasn't trying to be precise.

By the way, here's a deep philosophical question: is 0 seconds equal to 0 meters? I say yes. Zero of anything is just zero.

Russ P.


On Thu, Dec 16, 2010 at 3:34 PM, Kevin Wright <kev.lee.wright@gmail.com> wrote:

On 16 Dec 2010 23:14, "Sébastien Bocq" <sebastien.bocq@gmail.com> wrote:
>
>
> 2010/12/16 Russ Paielli <russ.paielli@gmail.com>
>
>>
>> On a side note, I've always wondered why the term "Unit" is used to represent essentially "Nothing" or "None".
>
>
> It is not. These are very different beasts.
>
> For example, a function that returns Unit may return control to the caller. A function that returns Nothing never returns control to the caller or must throw an exception. None is a subtype of Option and has another meaning.
>
> Also in the case of collections, a List[Unit] is not the same thing as a List[Nothing].
>
> Cheers,
> Sébastien

It's hard to imagine where you would return None,  that's like guaranteeing you'll return null - so pretty pointless.

Returning Nothing is the bottom type.  It subclasses everything, so you can happily call any method you want on it, knowing full well that control flow will never reach that far.  As in a method that always throws an exception - you can use the return value however you like.

Unit is like void: it returns, but not with a useable value.

--
http://RussP.us

2010/12/17 Russ Paielli <russ.paielli@gmail.com>

By the way, here's a deep philosophical question: is 0 seconds equal to 0 meters? I say yes. Zero of anything is just zero.

Until you add stuff to it. Have you ever heard of the clock monoid? Check here around 30:00:
http://channel9.msdn.com/Blogs/Charles/Brian-Beckman-Monads-Monoids-and-Mort

Don't fear the monoid.

2010/12/17 Kevin Wright <kev.lee.wright@gmail.com>

On 16 Dec 2010 23:14, "Sébastien Bocq" <sebastien.bocq@gmail.com> wrote:
>
>
> 2010/12/16 Russ Paielli <russ.paielli@gmail.com>
>
>>
>> On a side note, I've always wondered why the term "Unit" is used to represent essentially "Nothing" or "None".
>
>
> It is not. These are very different beasts.
>
> For example, a function that returns Unit may return control to the caller. A function that returns Nothing never returns control to the caller or must throw an exception. None is a subtype of Option and has another meaning.
>
> Also in the case of collections, a List[Unit] is not the same thing as a List[Nothing].
>
> Cheers,
> Sébastien

It's hard to imagine where you would return None,  that's like guaranteeing you'll return null - so pretty pointless.

Returning Nothing is the bottom type.  It subclasses everything, so you can happily call any method you want on it, knowing full well that control flow will never reach that far.  As in a method that always throws an exception - you can use the return value however you like.

Unit is like void: it returns, but not with a useable value.

One could also say then: "Unit is like None: it returns, but not with a useable value." :)

Am Freitag, 17. Dezember 2010, 02:52:27 schrieb Sébastien Bocq:
> 2010/12/17 Kevin Wright
>
> > On 16 Dec 2010 23:14, "Sébastien Bocq" wrote:
> > > 2010/12/16 Russ Paielli
> > >
> > >> On a side note, I've always wondered why the term "Unit" is used to
> >
> > represent essentially "Nothing" or "None".
> >
> > > It is not. These are very different beasts.
> > >
> > > For example, a function that returns Unit may return control to the
> >
> > caller. A function that returns Nothing never returns control to the
> > caller or must throw an exception. None is a subtype of Option and has
> > another meaning.
> >
> > > Also in the case of collections, a List[Unit] is not the same thing as
> > > a
> >
> > List[Nothing].
> >
> > > Cheers,
> > > Sébastien
> >
> > It's hard to imagine where you would return None, that's like
> > guaranteeing you'll return null - so pretty pointless.
> >
> > Returning Nothing is the bottom type. It subclasses everything, so you
> > can happily call any method you want on it, knowing full well that
> > control flow will never reach that far. As in a method that always
> > throws an exception - you can use the return value however you like.
> >
> > Unit is like void: it returns, but not with a useable value.
>
> One could also say then: "Unit is like None: it returns, but not with a
> useable value." :)

How do I guarantee to return None in scala (by signature)?
Well Option[Nothing] comes down to None in the end - but I have no idea how I
could state something like:
def f(): None = None

All I can say is
scala> def f(): Option[Nothing] = None
f: ()Option[Nothing]

however this is not the same signature as the inferred return type of
scala> def fn() = None
fn: ()object None

> One could also say then: "Unit is like None: it returns, but not with a
> useable value." :)

not precisely: you can't put Unit into something - it just can't be
remembered. None is a response which gives information back.
But I agree - a function always returning None might as well "return" Unit if
it is not to be used as function argument expected to return Option[_].

Greetings
Bernd

On Thursday December 16 2010, Bernd Johannes wrote:
> ...
>
> How do I guarantee to return None in scala (by signature)?

Welcome to Scala version 2.8.1.final (Java HotSpot(TM) Client VM, Java 1.6.0_22).
Type in expressions to have them evaluated.
Type :help for more information.

scala> def mNone(i: Int): None.type = None
mNone: (i: Int)None.type

scala> val n1 = mNone(23)
n1: None.type = None

scala> None
res0: None.type = None

> ...
>
> Bernd

Randall Schulz

Am Freitag, 17. Dezember 2010, 08:09:01 schrieb Randall R Schulz:
> On Thursday December 16 2010, Bernd Johannes wrote:
> > ...
> >
> > How do I guarantee to return None in scala (by signature)?
>
> Welcome to Scala version 2.8.1.final (Java HotSpot(TM) Client VM, Java
> 1.6.0_22). Type in expressions to have them evaluated.
> Type :help for more information.
>
> scala> def mNone(i: Int): None.type = None
> mNone: (i: Int)None.type
>

Ah well - looks quite obvious and straightforward. Something I've never used
before...
Thanks.

Greetings
Bernd

Hi Bernd,

Bernd Johannes wrote:
> How do I guarantee to return None in scala (by signature)?
> Well Option[Nothing] comes down to None in the end

This is only kind of true by enumeration the possible values. It's a subtle point, but

def foo : Option[Nothing] = Some({ throw new Exception })

is valid, whereas

def foo : None.type = Some({ throw new Exception })

is not.

>> One could also say then: "Unit is like None: it returns, but not with a
>> useable value." :)
>
> not precisely: you can't put Unit into something - it just can't be
> remembered. None is a response which gives information back.

There's nothing to stop you putting the unit value into something. For example,

Some(())

and

def foo(x : Unit) : String = "Hello World"

are both perfectly valid. They're just a bit boring!

The value () isn't overwhelmingly special anyway... It's just the unique instance of a
particular type. Were it not for all the existing libraries using Unit, and the compiler
treating Java void return types as Units, you could achieve mostly the same effect by
defining your own version and using that throughout your code. For example,

abstract sealed class Atom
object <> extends Atom

implicit def anyToAtom(x : Any) : Atom = <>

Cheers,
Jon

On Sun, Dec 19, 2010 at 12:51:13AM +0000, Jon Pretty wrote:
> The value () isn't overwhelmingly special anyway... It's just the
> unique instance of a particular type. Were it not for all the
> existing libraries using Unit, and the compiler treating Java void
> return types as Units, you could achieve mostly the same effect by
> defining your own version and using that throughout your code.

You're either glossing over a whole bunch of stuff or you will be
surprised to discover how special () is. With a different type, value
discarding would not take place; one-legged ifs would not produce it; it
would be an AnyRef instead of an AnyVal; I believe there are a lot more,
but my brain sifting pan is broken.

Hi Paul,

Paul Phillips wrote:
> You're either glossing over a whole bunch of stuff [...]

Yeah, I'm glossing over a whole bunch of stuff. ;-)

The main point I was trying to make was that () works a lot like a type with a unique value.

Cheers,
Jon

Am Sonntag, 19. Dezember 2010, 01:51:13 schrieb Jon Pretty:

> >> One could also say then: "Unit is like None: it returns, but not with a
> >> useable value." :)
> >
> > not precisely: you can't put Unit into something - it just can't be
> > remembered. None is a response which gives information back.
>
> There's nothing to stop you putting the unit value into something. For
> example,
>
> Some(())

Your completely right. I remember now that I read it quite a while ago. But
somehow my "mental model" changed and I took it for granted that Unit does not
represent a tangible value whatsoever.

But well:

Welcome to Scala version 2.8.0.final (GNU libgcj, Java 1.5.0).
Type in expressions to have them evaluated.
Type :help for more information.

scala> def fu(): Unit = {}
fu: ()Unit

scala> (1 to 5) map (x => fu) toList
res1: List[Unit] = List((), (), (), (), ())

scala> res1 match {
case ()::x => println("Unithead");
case _ => println("anything")
}
Unithead

here I stand corrected. :-)
Another reminder to check things first before trying to tell smart stories...

Greetings
Bernd

On Fri, Dec 17, 2010 at 12:23 PM, Bernd Johannes wrote:
> Am Freitag, 17. Dezember 2010, 08:09:01 schrieb Randall R Schulz:
>> On Thursday December 16 2010, Bernd Johannes wrote:
>> > ...
>> >
>> > How do I guarantee to return None in scala (by signature)?
>>
>> Welcome to Scala version 2.8.1.final (Java HotSpot(TM) Client VM, Java
>> 1.6.0_22). Type in expressions to have them evaluated.
>> Type :help for more information.
>>
>> scala> def mNone(i: Int): None.type = None
>> mNone: (i: Int)None.type
>>
>
> Ah well - looks quite obvious and straightforward.

But it isn't the type you asked for:

scala> def noneType(): None.type = None
noneType: ()None.type

scala> def noneTypeInferred() = None
noneTypeInferred: ()object None

scala> var j: () => None.type = noneType
j: () => None.type =

scala> j = noneTypeInferred
:7: error: type mismatch;
found : object None
required: None.type
j = noneTypeInferred
^

Am Montag, 20. Dezember 2010, 04:48:47 schrieb Jim Balter:
> On Fri, Dec 17, 2010 at 12:23 PM, Bernd Johannes wrote:
> > Am Freitag, 17. Dezember 2010, 08:09:01 schrieb Randall R Schulz:
> >> On Thursday December 16 2010, Bernd Johannes wrote:
> >> > ...
> >> >
> >> > How do I guarantee to return None in scala (by signature)?
> >>
> >> Welcome to Scala version 2.8.1.final (Java HotSpot(TM) Client VM, Java
> >> 1.6.0_22). Type in expressions to have them evaluated.
> >> Type :help for more information.
> >>
> >> scala> def mNone(i: Int): None.type = None
> >> mNone: (i: Int)None.type
> >
> > Ah well - looks quite obvious and straightforward.
>
> But it isn't the type you asked for:
>
> scala> def noneType(): None.type = None
> noneType: ()None.type
>
> scala> def noneTypeInferred() = None
> noneTypeInferred: ()object None
>
> scala> var j: () => None.type = noneType
> j: () => None.type =
>
> scala> j = noneTypeInferred
> :7: error: type mismatch;
> found : object None
> required: None.type
> j = noneTypeInferred
> ^

Uh... I feel like standing on quicksand here. Gladly it's not "my normal use
case" - so my limited knowledge in this scala regions doesn't strike me.
And as long as the compiler is complaining I can find my way around such
issues :-).

But from what the compiler is telling here: it takes the object/singleton
template type of None as different than the instantiated type of None?
(it reminds me of some of the this.type stuff I read... I must confess - it
tends to confuse me).

Greetings
Bernd

Well, I'm just a noob. I don't know why there are two types here,
"object Foo" which apparently can't be expressed in the language, and
its subtype Foo.type, and the two are inferred in different contexts;
I am hoping some expert can explain it. It certainly has very high
surprise value:

scala> object Foo
defined module Foo

scala> def f = Foo
f: object Foo

scala> var r = Foo
r: object Foo = Foo$@92524b0

scala> val l1 = f
l1: object Foo = Foo$@92524b0

scala> val l2 = Foo // infers Foo.type, unlike def and var
l2: Foo.type = Foo$@92524b0

scala> val l3: Foo.type = r
:7: error: type mismatch;
found : object Foo
required: Foo.type
val l3: Foo.type = r
^

On Sun, Dec 19, 2010 at 10:55 PM, Bernd Johannes wrote:
> Am Montag, 20. Dezember 2010, 04:48:47 schrieb Jim Balter:
>> On Fri, Dec 17, 2010 at 12:23 PM, Bernd Johannes wrote:
>> > Am Freitag, 17. Dezember 2010, 08:09:01 schrieb Randall R Schulz:
>> >> On Thursday December 16 2010, Bernd Johannes wrote:
>> >> > ...
>> >> >
>> >> > How do I guarantee to return None in scala (by signature)?
>> >>
>> >> Welcome to Scala version 2.8.1.final (Java HotSpot(TM) Client VM, Java
>> >> 1.6.0_22). Type in expressions to have them evaluated.
>> >> Type :help for more information.
>> >>
>> >> scala> def mNone(i: Int): None.type = None
>> >> mNone: (i: Int)None.type
>> >
>> > Ah well - looks quite obvious and straightforward.
>>
>> But it isn't the type you asked for:
>>
>> scala> def noneType(): None.type = None
>> noneType: ()None.type
>>
>> scala> def noneTypeInferred() = None
>> noneTypeInferred: ()object None
>>
>> scala> var j: () => None.type = noneType
>> j: () => None.type =
>>
>> scala> j = noneTypeInferred
>> :7: error: type mismatch;
>>  found   : object None
>>  required: None.type
>>        j = noneTypeInferred
>>            ^
>
> Uh... I feel like standing on quicksand here. Gladly it's not "my normal use
> case" - so my limited knowledge in this scala regions doesn't strike me.
> And as long as the compiler is complaining I can find my way around such
> issues :-).
>
> But from what the compiler is telling here: it takes the object/singleton
> template type of None as different than the instantiated type of None?
> (it reminds me of some of the this.type stuff I read... I must confess - it
> tends to confuse me).
>
> Greetings
> Bernd
>

AFAIK, and this is definitely one of the areas of Scala I'm very weak at, "object Foo" is the type of all Foo objects, while Foo.type is the type of this particular instance of Foo (which happens to be the only one).
On Mon, Dec 20, 2010 at 06:48, Jim Balter <Jim@balter.name> wrote:

Well, I'm just a noob. I don't know why there are two types here,
"object Foo" which apparently can't be expressed in the language, and
its subtype Foo.type, and the two are inferred in different contexts;
I am hoping some expert can explain it. It certainly has very high
surprise value:

scala> object Foo
defined module Foo

scala> def f = Foo
f: object Foo

scala> var r = Foo
r: object Foo = Foo$@92524b0

scala> val l1 = f
l1: object Foo = Foo$@92524b0

scala> val l2 = Foo // infers Foo.type, unlike def and var
l2: Foo.type = Foo$@92524b0

scala> val l3: Foo.type = r
<console>:7: error: type mismatch;
 found   : object Foo
 required: Foo.type
      val l3: Foo.type = r
                         ^

On Sun, Dec 19, 2010 at 10:55 PM, Bernd Johannes <bjohanns@bacon.de> wrote:
> Am Montag, 20. Dezember 2010, 04:48:47 schrieb Jim Balter:
>> On Fri, Dec 17, 2010 at 12:23 PM, Bernd Johannes <bjohanns@bacon.de> wrote:
>> > Am Freitag, 17. Dezember 2010, 08:09:01 schrieb Randall R Schulz:
>> >> On Thursday December 16 2010, Bernd Johannes wrote:
>> >> > ...
>> >> >
>> >> > How do I guarantee to return None in scala (by signature)?
>> >>
>> >> Welcome to Scala version 2.8.1.final (Java HotSpot(TM) Client VM, Java
>> >> 1.6.0_22). Type in expressions to have them evaluated.
>> >> Type :help for more information.
>> >>
>> >> scala> def mNone(i: Int): None.type = None
>> >> mNone: (i: Int)None.type
>> >
>> > Ah well - looks quite obvious and straightforward.
>>
>> But it isn't the type you asked for:
>>
>> scala> def noneType(): None.type = None
>> noneType: ()None.type
>>
>> scala> def noneTypeInferred() = None
>> noneTypeInferred: ()object None
>>
>> scala> var j: () => None.type = noneType
>> j: () => None.type = <function0>
>>
>> scala> j = noneTypeInferred
>> <console>:7: error: type mismatch;
>>  found   : object None
>>  required: None.type
>>        j = noneTypeInferred
>>            ^
>
> Uh... I feel like standing on quicksand here. Gladly it's not "my normal use
> case" - so my limited knowledge in this scala regions doesn't strike me.
> And as long as the compiler is complaining I can find my way around such
> issues :-).
>
> But from what the compiler is telling here: it takes the object/singleton
> template type of None as different than the instantiated type of None?
> (it reminds me of some of the this.type stuff I read... I must confess - it
> tends to confuse me).
>
> Greetings
> Bernd
>

--
Daniel C. Sobral

I travel to the future all the time.

AFAIK, and this is definitely one of the areas of Scala I'm very weak at, "object Foo" is the type of all Foo objects, while Foo.type is the type of this particular instance of Foo (which happens to be the only one).

 I'm sure you already know all this Daniel, but for the record:

For "object Foo", "Foo" is the name of a value, not a class.  Under the hood the class name is "Foo$", but this is not typically used by code.   XXX.type always gives the type of some fixed value called XXX, so since object Foo is a fixed value, Foo.type is the type of that particular instance, as you say.

Ken

Hmmm ... my object Foo is not of type Foo, so what is "all Foo
objects" and when isn't there only one, since "object" means a
singleton? And why isn't this type expressible in Scala? And why is
object Foo inferred for var and def but Foo.type is inferred for val?
Can someone strong in this area help, please?

On Mon, Dec 20, 2010 at 3:47 PM, Daniel Sobral wrote:
> AFAIK, and this is definitely one of the areas of Scala I'm very weak at,
> "object Foo" is the type of all Foo objects, while Foo.type is the type of
> this particular instance of Foo (which happens to be the only one).
>
> On Mon, Dec 20, 2010 at 06:48, Jim Balter wrote:
>>
>> Well, I'm just a noob. I don't know why there are two types here,
>> "object Foo" which apparently can't be expressed in the language, and
>> its subtype Foo.type, and the two are inferred in different contexts;
>> I am hoping some expert can explain it. It certainly has very high
>> surprise value:
>>
>> scala> object Foo
>> defined module Foo
>>
>> scala> def f = Foo
>> f: object Foo
>>
>> scala> var r = Foo
>> r: object Foo = Foo$@92524b0
>>
>> scala> val l1 = f
>> l1: object Foo = Foo$@92524b0
>>
>> scala> val l2 = Foo // infers Foo.type, unlike def and var
>> l2: Foo.type = Foo$@92524b0
>>
>> scala> val l3: Foo.type = r
>> :7: error: type mismatch;
>>  found   : object Foo
>>  required: Foo.type
>>       val l3: Foo.type = r
>>                          ^
>>
>> On Sun, Dec 19, 2010 at 10:55 PM, Bernd Johannes
>> wrote:
>> > Am Montag, 20. Dezember 2010, 04:48:47 schrieb Jim Balter:
>> >> On Fri, Dec 17, 2010 at 12:23 PM, Bernd Johannes
>> >> wrote:
>> >> > Am Freitag, 17. Dezember 2010, 08:09:01 schrieb Randall R Schulz:
>> >> >> On Thursday December 16 2010, Bernd Johannes wrote:
>> >> >> > ...
>> >> >> >
>> >> >> > How do I guarantee to return None in scala (by signature)?
>> >> >>
>> >> >> Welcome to Scala version 2.8.1.final (Java HotSpot(TM) Client VM,
>> >> >> Java
>> >> >> 1.6.0_22). Type in expressions to have them evaluated.
>> >> >> Type :help for more information.
>> >> >>
>> >> >> scala> def mNone(i: Int): None.type = None
>> >> >> mNone: (i: Int)None.type
>> >> >
>> >> > Ah well - looks quite obvious and straightforward.
>> >>
>> >> But it isn't the type you asked for:
>> >>
>> >> scala> def noneType(): None.type = None
>> >> noneType: ()None.type
>> >>
>> >> scala> def noneTypeInferred() = None
>> >> noneTypeInferred: ()object None
>> >>
>> >> scala> var j: () => None.type = noneType
>> >> j: () => None.type =
>> >>
>> >> scala> j = noneTypeInferred
>> >> :7: error: type mismatch;
>> >>  found   : object None
>> >>  required: None.type
>> >>        j = noneTypeInferred
>> >>            ^
>> >
>> > Uh... I feel like standing on quicksand here. Gladly it's not "my normal
>> > use
>> > case" - so my limited knowledge in this scala regions doesn't strike me.
>> > And as long as the compiler is complaining I can find my way around such
>> > issues :-).
>> >
>> > But from what the compiler is telling here: it takes the
>> > object/singleton
>> > template type of None as different than the instantiated type of None?
>> > (it reminds me of some of the this.type stuff I read... I must confess -
>> > it
>> > tends to confuse me).
>> >
>> > Greetings
>> > Bernd
>> >
>
>
>
> --
> Daniel C. Sobral
>
> I travel to the future all the time.
>

On Mon, Dec 20, 2010 at 22:00, Ken Scambler <ken.scambler@gmail.com> wrote:

AFAIK, and this is definitely one of the areas of Scala I'm very weak at, "object Foo" is the type of all Foo objects, while Foo.type is the type of this particular instance of Foo (which happens to be the only one).

 I'm sure you already know all this Daniel, but for the record:

For "object Foo", "Foo" is the name of a value, not a class.  Under the hood the class name is "Foo$", but this is not typically used by code.   XXX.type always gives the type of some fixed value called XXX, so since object Foo is a fixed value, Foo.type is the type of that particular instance, as you say.

I meant as Scala describes them:
scala> object Xdefined module X
scala> X res0: X.type = X$@2688e83d
scala> def f = Xf: object X
I'd be more than happy to be corrected on this. And, in this particular case, I _don't_ know better! 

--
Daniel C. Sobral

I travel to the future all the time.

On Mon, Dec 20, 2010 at 22:00, Jim Balter <Jim@balter.name> wrote:

Hmmm ... my object Foo is not of type Foo, so what is "all Foo
objects" and when isn't there only one, since "object" means a
singleton? And why isn't this type expressible in Scala? And why is
object Foo inferred for var and def but Foo.type is inferred for val?
Can someone strong in this area help, please?

The other way around, Jim:
scala> scala> Xres0: X.type = X$@2688e83d
scala> def f = Xf: object X
scala> var x = fx: object X = X$@64b9726e
scala> x = Xx: object X = X$@64b9726e
scala> var y: X.type = Xy: X.type = X$@64b9726e
scala> y = f<console>:8: error: type mismatch; found   : object X required: X.type        y = f           ^
The subclassing would go like this: X.type <:< object X <:< AnyRef. Not that I have been able to show any evidence of the existance of distincts "object X" and "X.type" aside from the example above.  --
Daniel C. Sobral

I travel to the future all the time.

On 21 December 2010 11:00, Jim Balter <Jim@balter.name> wrote:

Hmmm ... my object Foo is not of type Foo, so what is "all Foo
objects" and when isn't there only one, since "object" means a
singleton? And why isn't this type expressible in Scala? And why is
object Foo inferred for var and def but Foo.type is inferred for val?
Can someone strong in this area help, please?

I think I can answer this:  remember, XXX.type is the type of a fixed value XXX.  val foo = ... is a fixed value, whereas def foo = ... and var foo = ... could hold any value every time you access them. 

Cheers,
Ken