This page is no longer maintained — Please continue to the home page at www.scala-lang.org

Options and [SLS 4.2 - var x: T = _]

4 replies
loverdos
Joined: 2008-11-18,
User offline. Last seen 2 years 27 weeks ago.
I know there have been discussions on using Options to avoid null altogether (with proper underlying compiler oprimisations) and I will not go into another debate of the kind right here.
I was just wondering if changing the semantics of default initial values for Options, so that
var x: Option[T] = _
means
var x: Option[T] = None
instead of
var x: Option[T] = null
might be something to go for. 


Thoughts?
Christos
--
 __~O
-\ <,       Christos KK Loverdos
(*)/ (*)      http://ckkloverdos.com
thebugslayer
Joined: 2008-08-20,
User offline. Last seen 3 years 23 weeks ago.
Re: Options and [SLS 4.2 - var x: T = _]
Christos,

-1

I think many have voiced that "_" means too many things. Adding this rule would just add another exception to remember among the other meanings. I personally like initializing by explicit value is better than using "_".

zemian

On Sat, Dec 20, 2008 at 10:00 AM, Christos KK Loverdos <loverdos [at] gmail [dot] com> wrote:
I know there have been discussions on using Options to avoid null altogether (with proper underlying compiler oprimisations) and I will not go into another debate of the kind right here.
I was just wondering if changing the semantics of default initial values for Options, so that
var x: Option[T] = _
means
var x: Option[T] = None
instead of
var x: Option[T] = null
might be something to go for. 


Thoughts?
Christos
--
 __~O
-\ <,       Christos KK Loverdos
(*)/ (*)      http://ckkloverdos.com



--
http://www.jroller.com/thebugslayer

Szymon Jachim
Joined: 2008-12-17,
User offline. Last seen 42 years 45 weeks ago.
Re: Options and [SLS 4.2 - var x: T = _]
But wouldn't it be useful if compiler looked for implicit converson like below before assuming the somethings default value ("_") is null?

implicit def nullValue(n: Nothing): AClassName = {  // ... }
Szymon

On Sat, Dec 20, 2008 at 5:04 PM, Zemian Deng <thebugslayer [at] gmail [dot] com> wrote:
Christos,

-1

I think many have voiced that "_" means too many things. Adding this rule would just add another exception to remember among the other meanings. I personally like initializing by explicit value is better than using "_".

zemian

On Sat, Dec 20, 2008 at 10:00 AM, Christos KK Loverdos <loverdos [at] gmail [dot] com> wrote:
I know there have been discussions on using Options to avoid null altogether (with proper underlying compiler oprimisations) and I will not go into another debate of the kind right here.
I was just wondering if changing the semantics of default initial values for Options, so that
var x: Option[T] = _
means
var x: Option[T] = None
instead of
var x: Option[T] = null
might be something to go for. 


Thoughts?
Christos
--
 __~O
-\ <,       Christos KK Loverdos
(*)/ (*)      http://ckkloverdos.com



--
http://www.jroller.com/thebugslayer


Andrew Forrest
Joined: 2008-12-20,
User offline. Last seen 42 years 45 weeks ago.
Re: Options and [SLS 4.2 - var x: T = _]
What about a method Predef.default[T].... which returns the default value for T?
So you could write var x: Option[Blah] = default

(In which case x would be assigned 'None'.)
I tend to agree that '_' is overloaded plenty already in Scala, and none of its current meanings really have much to do with the concept of 'default'. It's generally used to mean 'something goes here', where the 'something' is variable. Whereas the value returned by 'default' doesn't change.
As an aside, we'd probably want a safe way to ask if a type /has/ a default, so something like
def optionalDefault[T]: Option[T] = if (T has a default value) Some(default[T]) else None



On 20 Dec 2008, at 19:27, Szymon Jachim wrote:
But wouldn't it be useful if compiler looked for implicit converson like below before assuming the somethings default value ("_") is null?

implicit def nullValue(n: Nothing): AClassName = {  // ... }
Szymon

On Sat, Dec 20, 2008 at 5:04 PM, Zemian Deng <thebugslayer [at] gmail [dot] com> wrote:
Christos,

-1

I think many have voiced that "_" means too many things. Adding this rule would just add another exception to remember among the other meanings. I personally like initializing by explicit value is better than using "_".

zemian

On Sat, Dec 20, 2008 at 10:00 AM, Christos KK Loverdos <loverdos [at] gmail [dot] com> wrote:
I know there have been discussions on using Options to avoid null altogether (with proper underlying compiler oprimisations) and I will not go into another debate of the kind right here.
I was just wondering if changing the semantics of default initial values for Options, so that
var x: Option[T] = _
means
var x: Option[T] = None
instead of
var x: Option[T] = null
might be something to go for. 


Thoughts?
Christos
--
 __~O
-\ <,       Christos KK Loverdos
(*)/ (*)      http://ckkloverdos.com



--
http://www.jroller.com/thebugslayer



Jorge Ortiz
Joined: 2008-12-16,
User offline. Last seen 29 weeks 3 days ago.
Re: Options and [SLS 4.2 - var x: T = _]
You can implement "default" yourself. I see no reason why this should go in Predef.

--j

On Sat, Dec 20, 2008 at 1:39 PM, Andrew Forrest <andrew [at] dysphoria [dot] net> wrote:
What about a method Predef.default[T].... which returns the default value for T?
So you could write var x: Option[Blah] = default

(In which case x would be assigned 'None'.)
I tend to agree that '_' is overloaded plenty already in Scala, and none of its current meanings really have much to do with the concept of 'default'. It's generally used to mean 'something goes here', where the 'something' is variable. Whereas the value returned by 'default' doesn't change.
As an aside, we'd probably want a safe way to ask if a type /has/ a default, so something like
def optionalDefault[T]: Option[T] = if (T has a default value) Some(default[T]) else None



On 20 Dec 2008, at 19:27, Szymon Jachim wrote:
But wouldn't it be useful if compiler looked for implicit converson like below before assuming the somethings default value ("_") is null?

implicit def nullValue(n: Nothing): AClassName = {  // ... }
Szymon

On Sat, Dec 20, 2008 at 5:04 PM, Zemian Deng <thebugslayer [at] gmail [dot] com> wrote:
Christos,

-1

I think many have voiced that "_" means too many things. Adding this rule would just add another exception to remember among the other meanings. I personally like initializing by explicit value is better than using "_".

zemian

On Sat, Dec 20, 2008 at 10:00 AM, Christos KK Loverdos <loverdos [at] gmail [dot] com> wrote:
I know there have been discussions on using Options to avoid null altogether (with proper underlying compiler oprimisations) and I will not go into another debate of the kind right here.
I was just wondering if changing the semantics of default initial values for Options, so that
var x: Option[T] = _
means
var x: Option[T] = None
instead of
var x: Option[T] = null
might be something to go for. 


Thoughts?
Christos
--
 __~O
-\ <,       Christos KK Loverdos
(*)/ (*)      http://ckkloverdos.com



--
http://www.jroller.com/thebugslayer




Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland