- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
Cost of Option / Some vs null
Does scalac implement some kind of magic so that
using Option[T] is as efficient as using nulls ?
Of course Option is a wrapper so the extra cost should
be one thin object. I was just writing a tight loop
and was trying to make it lean and mean. I got tempted
to depart from idiomatic scala here and use a good old null,
it got me wondering if this kind of magic be doable by
the compiler ? (And is it doing it ?)
Cheers
Re: Cost of Option / Some vs null
Using option, the same person might write: val x = 5 + foo.get().integerValue // may throw NoSuchElementException because foo may be None
On Sat, Nov 21, 2009 at 6:52 AM, Tony Morris <tonymorris [at] gmail [dot] com> wrote:
--
http://erikengbrecht.blogspot.com/
Re: Cost of Option / Some vs null
Erik Engbrecht schrieb:
> Using option, the same person might write:
> val x = 5 + foo.get().integerValue // may throw NoSuchElementException
> because foo may be None
And some would argue that you should really write something like
this to avoid all the case matches and if/else constructs:
scala> def addFive(foo: Option[Int]) = foo map (_ + 5)
addFive: (Option[Int])Option[Int]
scala> addFive(None)
res0: Option[Int] = None
scala> addFive(Some(4))
res1: Option[Int] = Some(9)
This works equally well for Tony's Optionn:
scala> def addFiveN(foo: Optionn[Int]) = foo map (_ + 5)
addFiveN: (Optionn[Int])java.lang.Object with Optionn[Int]
scala> object NoneN extends Optionn[Nothing] {
| def cata[X](ding: Nothing => X, dong: => X) = dong
| }
defined module NoneN
scala> class SomeN[T](x: T) extends Optionn[T] {
| def cata[X](ding: T => X, dong: => X) = ding(x)
| }
defined class SomeN
scala> addFiveN(NoneN) cata (x => "SomeN(" + x.toString + ")", "NoneN")
res16: java.lang.String = NoneN
scala> addFiveN(new SomeN(4)) cata (x => "SomeN(" + x.toString + ")", "NoneN")
res17: java.lang.String = SomeN(9)
- Florian
Re: Cost of Option / Some vs null
Tony Morris schrieb:
> Stepan Koltsov wrote:
>> You probably missed parts of the discussion where explained how Option
>> changes NullPointerException to NoSuchElementException.
>>
> Except it doesn't.
>
I'm just--thanks to Paolo Losi!--listening to Tony Hoare, some CS guy I
hadn't known before. He's a real British gentleman, one of a kind I
presumed extinct already. It is really a pleasure to listen to him. But
I don't think I agree with his basic point: Null pointers are bad. A
German guy posed the right question, and maybe because he asked it in
broken English, not a lot attention was paid. This German guy asked:
``If you make 0 a class, then you only defer the necessary runtime
checks." Mr. Hoare gave no answer on this.
---Ph.
Re: Cost of Option / Some vs null
Tony Hoare is exceptional . You should listen to him more often. Try not
to disagree so hastily.
Philip Köster wrote:
>
>
> Tony Morris schrieb:
>> Stepan Koltsov wrote:
>>> You probably missed parts of the discussion where explained how Option
>>> changes NullPointerException to NoSuchElementException.
>>>
>> Except it doesn't.
>>
>
> I'm just--thanks to Paolo Losi!--listening to Tony Hoare, some CS guy
> I hadn't known before. He's a real British gentleman, one of a kind I
> presumed extinct already. It is really a pleasure to listen to him.
> But I don't think I agree with his basic point: Null pointers are bad.
> A German guy posed the right question, and maybe because he asked it
> in broken English, not a lot attention was paid. This German guy
> asked: ``If you make 0 a class, then you only defer the necessary
> runtime checks." Mr. Hoare gave no answer on this.
>
> ---Ph.
>
Re: Cost of Option / Some vs null
> Tony Hoare is exceptional . You should listen to him more often. Try not
> to disagree so hastily.
I do not claim to be right, but I know that we should use the tools
Mother Nature gave us, and 0 is at the very heart of our nature. We
don't need a class modeling 0, because the 0 is there, waiting, ready to
be used. It needs no model, just as 1, 2, 3 ... don't need a model.
Programming languages should enable me to declare a method so that I can
say whether or not I'm ready to receive a 0 value or not. There's
nothing special about the 0, except that it is ``to be or not to be."
Re: Cost of Option / Some vs null
Me, I'm with the people who say manual memory management, and, therefore, pointers, have no place in modern languages. So, out with pointers, of which null is a value.
Now, if I'm handling strings, I'm handling strings. I don't want to get a pointer instead.
On Sat, Nov 21, 2009 at 4:03 AM, Philip Köster <philip [dot] koester [at] web [dot] de> wrote:
--
Daniel C. Sobral
Veni, vidi, veterni.
Re: Cost of Option / Some vs null
Look up "Church Numeral Encoding."
Philip Köster wrote:
>> Tony Hoare is exceptional . You should listen to him more often. Try not
>> to disagree so hastily.
>
> I do not claim to be right, but I know that we should use the tools
> Mother Nature gave us, and 0 is at the very heart of our nature. We
> don't need a class modeling 0, because the 0 is there, waiting, ready
> to be used. It needs no model, just as 1, 2, 3 ... don't need a model.
> Programming languages should enable me to declare a method so that I
> can say whether or not I'm ready to receive a 0 value or not. There's
> nothing special about the 0, except that it is ``to be or not to be."
>
Re: Cost of Option / Some vs null
This is the sort of mails that I, frankly, don't like: "Look up this."
Mails like these free you from saying anything, from expressing your own
opinion. I could, Tony, say in the same way ``Go read Hemingway and
Foster and get a life," or say "Go read Niklaus Wirth and get real."
This would not help anyone. What is Church Numeral Encoding? That rings
a bell, I heard about it, but I'm not interested in that unless you tell
me what you find interesting about that, in your own words. Why would I
need Church Numeral Encoding, and how does it make my life easier?
Tony Morris schrieb:
> Look up "Church Numeral Encoding."
>
> Philip Köster wrote:
>>> Tony Hoare is exceptional . You should listen to him more often. Try not
>>> to disagree so hastily.
>> I do not claim to be right, but I know that we should use the tools
>> Mother Nature gave us, and 0 is at the very heart of our nature. We
>> don't need a class modeling 0, because the 0 is there, waiting, ready
>> to be used. It needs no model, just as 1, 2, 3 ... don't need a model.
>> Programming languages should enable me to declare a method so that I
>> can say whether or not I'm ready to receive a 0 value or not. There's
>> nothing special about the 0, except that it is ``to be or not to be."
>>
>
Re: Cost of Option / Some vs null
http://en.wikipedia.org/wiki/Church_encoding
On Sat, Nov 21, 2009 at 1:25 AM, Philip Köster <philip [dot] koester [at] web [dot] de> wrote:
--
http://erikengbrecht.blogspot.com/
Re: Cost of Option / Some vs null
> Thankfully we have Google and Wikipedia so that basic references are
> free and only a few keystrokes away.
Ihr nervt mich gerade mit Euerm Church-Encoding, aber das ist schon okay ...
Re: Cost of Option / Some vs null
On 21/11/2009 12:55, Philip Köster wrote:
>> Thankfully we have Google and Wikipedia so that basic references are
>> free and only a few keystrokes away.
>
> Ihr nervt mich gerade mit Euerm Church-Encoding, aber das ist schon okay
> ...
Please respect the lang policy of the list. This mailing list is English
only, try to respect other readers, even if it seems hard.
Re: Cost of Option / Some vs null
C'mon François, take it eaaasy ! These days there's all this rave about
polyglot programming, can't we take it one step further ?
Prend ça cooool Mec ! ;-)
Cheers !
On Sat, Nov 21, 2009 at 7:01 AM, Francois <fanf42 [at] gmail [dot] com> wrote:
Re: Cost of Option / Some vs null
This is the sort of email I dislike, the one where someone takes a
suggestion to learn something and reacts with a closed mind.
It's turning these lists to shit.
2009/11/21 Philip Köster :
> This is the sort of mails that I, frankly, don't like: "Look up this." Mails
> like these free you from saying anything, from expressing your own opinion.
> I could, Tony, say in the same way ``Go read Hemingway and Foster and get a
> life," or say "Go read Niklaus Wirth and get real." This would not help
> anyone. What is Church Numeral Encoding? That rings a bell, I heard about
> it, but I'm not interested in that unless you tell me what you find
> interesting about that, in your own words. Why would I need Church Numeral
> Encoding, and how does it make my life easier?
>
> Tony Morris schrieb:
>>
>> Look up "Church Numeral Encoding."
>>
>> Philip Köster wrote:
>>>>
>>>> Tony Hoare is exceptional . You should listen to him more often. Try not
>>>> to disagree so hastily.
>>>
>>> I do not claim to be right, but I know that we should use the tools
>>> Mother Nature gave us, and 0 is at the very heart of our nature. We
>>> don't need a class modeling 0, because the 0 is there, waiting, ready
>>> to be used. It needs no model, just as 1, 2, 3 ... don't need a model.
>>> Programming languages should enable me to declare a method so that I
>>> can say whether or not I'm ready to receive a 0 value or not. There's
>>> nothing special about the 0, except that it is ``to be or not to be."
>>>
>>
>
Re: Cost of Option / Some vs null
> This is the sort of email I dislike, the one where someone takes a
> suggestion to learn something and reacts with a closed mind.
>
> It's turning these lists to shit.
This wasn't my intention. I worship your posts, as well as Tony's, but
it appears that I sometimes have a hard time to carry out a conflict
without getting insulting. This is the way my mouth grew (in German we
say ``So ist mir der Schnabel gewachsen"), and I really didn't mean to
insult anyone. We all share the love of computer programming, so we
shouldn't hack on each other.
Please take my apologies
---Phil
PS: The inition of this discussion was whether 0 should be made a class.
There are contradictory opionions here, and this should not end in a
fight. I'm awfully sorry should I have been a flamer.
Re: Cost of Option / Some vs null
Accepted. This list has had its recent good dose of... non-thinking.
Instead, let's have some fun. Announcing the new scala.Option without
any case classes or objects!
trait Optionn[+A] {
// Church Encoding (abstract method)
def cata[X](ding: A => X, dong: => X): X
// Look ma, no case classes!
def map[B](f: A => B) = new Optionn[B] {
def cata[X](ding: B => X, dong: => X) = Optionn.this.cata(ding
compose f, dong)
}
def flatMap[B](f: A => Optionn[B]) = new Optionn[B] {
def cata[X](ding: B => X, dong: => X) =
Optionn.this.cata(f(_).cata(ding, dong), dong)
}
}
Philip Köster wrote:
>> This is the sort of email I dislike, the one where someone takes a
>> suggestion to learn something and reacts with a closed mind.
>>
>> It's turning these lists to shit.
>
> This wasn't my intention. I worship your posts, as well as Tony's, but
> it appears that I sometimes have a hard time to carry out a conflict
> without getting insulting. This is the way my mouth grew (in German we
> say ``So ist mir der Schnabel gewachsen"), and I really didn't mean to
> insult anyone. We all share the love of computer programming, so we
> shouldn't hack on each other.
>
> Please take my apologies
> ---Phil
>
> PS: The inition of this discussion was whether 0 should be made a
> class. There are contradictory opionions here, and this should not end
> in a fight. I'm awfully sorry should I have been a flamer.
>
Re: Cost of Option / Some vs null
I should have also pointed out that the 'cata' method below has the same
signature as Option's map + getOrElse.
Tony Morris wrote:
> Accepted. This list has had its recent good dose of... non-thinking.
>
> Instead, let's have some fun. Announcing the new scala.Option without
> any case classes or objects!
>
>
> trait Optionn[+A] {
> // Church Encoding (abstract method)
> def cata[X](ding: A => X, dong: => X): X
>
> // Look ma, no case classes!
> def map[B](f: A => B) = new Optionn[B] {
> def cata[X](ding: B => X, dong: => X) = Optionn.this.cata(ding
> compose f, dong)
> }
>
> def flatMap[B](f: A => Optionn[B]) = new Optionn[B] {
> def cata[X](ding: B => X, dong: => X) =
> Optionn.this.cata(f(_).cata(ding, dong), dong)
> }
> }
>
>
> Philip Köster wrote:
>
>>> This is the sort of email I dislike, the one where someone takes a
>>> suggestion to learn something and reacts with a closed mind.
>>>
>>> It's turning these lists to shit.
>>>
>> This wasn't my intention. I worship your posts, as well as Tony's, but
>> it appears that I sometimes have a hard time to carry out a conflict
>> without getting insulting. This is the way my mouth grew (in German we
>> say ``So ist mir der Schnabel gewachsen"), and I really didn't mean to
>> insult anyone. We all share the love of computer programming, so we
>> shouldn't hack on each other.
>>
>> Please take my apologies
>> ---Phil
>>
>> PS: The inition of this discussion was whether 0 should be made a
>> class. There are contradictory opionions here, and this should not end
>> in a fight. I'm awfully sorry should I have been a flamer.
>>
>>
>
>
Re: Cost of Option / Some vs null
I have no clue what this is about. No fun for me. :)
May I remind the dear audience of J. R. R. Tolkien? The Ents said,
```mountain' is too short a word for something that's been there all the
time." Likewise, ``Boolean" is too long a word representing a flag. I
find it a pity that the designers of Scala did not make that a `bool',
or `Bool', meinetwegen.
Tony Morris schrieb:
> I should have also pointed out that the 'cata' method below has the same
> signature as Option's map + getOrElse.
>
> Tony Morris wrote:
>> Accepted. This list has had its recent good dose of... non-thinking.
>>
>> Instead, let's have some fun. Announcing the new scala.Option without
>> any case classes or objects!
>>
>>
>> trait Optionn[+A] {
>> // Church Encoding (abstract method)
>> def cata[X](ding: A => X, dong: => X): X
>>
>> // Look ma, no case classes!
>> def map[B](f: A => B) = new Optionn[B] {
>> def cata[X](ding: B => X, dong: => X) = Optionn.this.cata(ding
>> compose f, dong)
>> }
>>
>> def flatMap[B](f: A => Optionn[B]) = new Optionn[B] {
>> def cata[X](ding: B => X, dong: => X) =
>> Optionn.this.cata(f(_).cata(ding, dong), dong)
>> }
>> }
>>
>>
>> Philip Köster wrote:
>>
>>>> This is the sort of email I dislike, the one where someone takes a
>>>> suggestion to learn something and reacts with a closed mind.
>>>>
>>>> It's turning these lists to shit.
>>>>
>>> This wasn't my intention. I worship your posts, as well as Tony's, but
>>> it appears that I sometimes have a hard time to carry out a conflict
>>> without getting insulting. This is the way my mouth grew (in German we
>>> say ``So ist mir der Schnabel gewachsen"), and I really didn't mean to
>>> insult anyone. We all share the love of computer programming, so we
>>> shouldn't hack on each other.
>>>
>>> Please take my apologies
>>> ---Phil
>>>
>>> PS: The inition of this discussion was whether 0 should be made a
>>> class. There are contradictory opionions here, and this should not end
>>> in a fight. I'm awfully sorry should I have been a flamer.
>>>
>>>
>>
>
Re: Cost of Option / Some vs null
Philip Köster wrote:
> I have no clue what this is about. No fun for me. :)
It's not that hard. It's Scala. Read it. Compile it. Observe certain
properties about it, such as providing exactly the same interface as
scala.Option, but without the case object/class and a single abstract
method. How does it work? Why does it work? Does this have a name? Is it
exactly the same interface i.e. I see map and flatMap but what about
others? Can I write my own Option methods on it?
Think, try it, it's fun.
>
> May I remind the dear audience of J. R. R. Tolkien? The Ents said,
> ```mountain' is too short a word for something that's been there all
> the time." Likewise, ``Boolean" is too long a word representing a
> flag. I find it a pity that the designers of Scala did not make that a
> `bool', or `Bool', meinetwegen.
>
>
>
> Tony Morris schrieb:
>> I should have also pointed out that the 'cata' method below has the same
>> signature as Option's map + getOrElse.
>>
>> Tony Morris wrote:
>>> Accepted. This list has had its recent good dose of... non-thinking.
>>>
>>> Instead, let's have some fun. Announcing the new scala.Option without
>>> any case classes or objects!
>>>
>>>
>>> trait Optionn[+A] {
>>> // Church Encoding (abstract method)
>>> def cata[X](ding: A => X, dong: => X): X
>>>
>>> // Look ma, no case classes!
>>> def map[B](f: A => B) = new Optionn[B] {
>>> def cata[X](ding: B => X, dong: => X) = Optionn.this.cata(ding
>>> compose f, dong)
>>> }
>>>
>>> def flatMap[B](f: A => Optionn[B]) = new Optionn[B] {
>>> def cata[X](ding: B => X, dong: => X) =
>>> Optionn.this.cata(f(_).cata(ding, dong), dong)
>>> }
>>> }
>>>
>>>
>>> Philip Köster wrote:
>>>
>>>>> This is the sort of email I dislike, the one where someone takes a
>>>>> suggestion to learn something and reacts with a closed mind.
>>>>>
>>>>> It's turning these lists to shit.
>>>>>
>>>> This wasn't my intention. I worship your posts, as well as Tony's, but
>>>> it appears that I sometimes have a hard time to carry out a conflict
>>>> without getting insulting. This is the way my mouth grew (in German we
>>>> say ``So ist mir der Schnabel gewachsen"), and I really didn't mean to
>>>> insult anyone. We all share the love of computer programming, so we
>>>> shouldn't hack on each other.
>>>>
>>>> Please take my apologies
>>>> ---Phil
>>>>
>>>> PS: The inition of this discussion was whether 0 should be made a
>>>> class. There are contradictory opionions here, and this should not end
>>>> in a fight. I'm awfully sorry should I have been a flamer.
>>>>
>>>>
>>>
>>
>
Re: Cost of Option / Some vs null
Coming back to Mr Köster's original dilemma, I tend to explain it to
my coworkers in our Java shop as "pretty much like null, except that
the compiler forces you to handle it".
Am I off the crease on this? It seems relatively straight-forward to
me, and I'm a very junior dev, but Option combined with Scala's match
construct, and the cleaner and more robust code you get as a result is
what made me overlook the syntax in the early Scala code examples I
saw that looked like a game of Hangman.
On 11/21/09, Tony Morris wrote:
> Philip Köster wrote:
>> I have no clue what this is about. No fun for me. :)
> It's not that hard. It's Scala. Read it. Compile it. Observe certain
> properties about it, such as providing exactly the same interface as
> scala.Option, but without the case object/class and a single abstract
> method. How does it work? Why does it work? Does this have a name? Is it
> exactly the same interface i.e. I see map and flatMap but what about
> others? Can I write my own Option methods on it?
>
> Think, try it, it's fun.
>
>>
>> May I remind the dear audience of J. R. R. Tolkien? The Ents said,
>> ```mountain' is too short a word for something that's been there all
>> the time." Likewise, ``Boolean" is too long a word representing a
>> flag. I find it a pity that the designers of Scala did not make that a
>> `bool', or `Bool', meinetwegen.
>>
>>
>>
>> Tony Morris schrieb:
>>> I should have also pointed out that the 'cata' method below has the same
>>> signature as Option's map + getOrElse.
>>>
>>> Tony Morris wrote:
>>>> Accepted. This list has had its recent good dose of... non-thinking.
>>>>
>>>> Instead, let's have some fun. Announcing the new scala.Option without
>>>> any case classes or objects!
>>>>
>>>>
>>>> trait Optionn[+A] {
>>>> // Church Encoding (abstract method)
>>>> def cata[X](ding: A => X, dong: => X): X
>>>>
>>>> // Look ma, no case classes!
>>>> def map[B](f: A => B) = new Optionn[B] {
>>>> def cata[X](ding: B => X, dong: => X) = Optionn.this.cata(ding
>>>> compose f, dong)
>>>> }
>>>>
>>>> def flatMap[B](f: A => Optionn[B]) = new Optionn[B] {
>>>> def cata[X](ding: B => X, dong: => X) =
>>>> Optionn.this.cata(f(_).cata(ding, dong), dong)
>>>> }
>>>> }
>>>>
>>>>
>>>> Philip Köster wrote:
>>>>
>>>>>> This is the sort of email I dislike, the one where someone takes a
>>>>>> suggestion to learn something and reacts with a closed mind.
>>>>>>
>>>>>> It's turning these lists to shit.
>>>>>>
>>>>> This wasn't my intention. I worship your posts, as well as Tony's, but
>>>>> it appears that I sometimes have a hard time to carry out a conflict
>>>>> without getting insulting. This is the way my mouth grew (in German we
>>>>> say ``So ist mir der Schnabel gewachsen"), and I really didn't mean to
>>>>> insult anyone. We all share the love of computer programming, so we
>>>>> shouldn't hack on each other.
>>>>>
>>>>> Please take my apologies
>>>>> ---Phil
>>>>>
>>>>> PS: The inition of this discussion was whether 0 should be made a
>>>>> class. There are contradictory opionions here, and this should not end
>>>>> in a fight. I'm awfully sorry should I have been a flamer.
>>>>>
>>>>>
>>>>
>>>
>>
>
> --
> Tony Morris
> http://tmorris.net/
>
>
>
Re: Cost of Option / Some vs null
Don't look up "Church Numeral Encoding."
Philip Köster wrote:
> This is the sort of mails that I, frankly, don't like: "Look up this."
> Mails like these free you from saying anything, from expressing your
> own opinion. I could, Tony, say in the same way ``Go read Hemingway
> and Foster and get a life," or say "Go read Niklaus Wirth and get
> real." This would not help anyone. What is Church Numeral Encoding?
> That rings a bell, I heard about it, but I'm not interested in that
> unless you tell me what you find interesting about that, in your own
> words. Why would I need Church Numeral Encoding, and how does it make
> my life easier?
>
> Tony Morris schrieb:
>> Look up "Church Numeral Encoding."
>>
>> Philip Köster wrote:
>>>> Tony Hoare is exceptional . You should listen to him more often.
>>>> Try not
>>>> to disagree so hastily.
>>> I do not claim to be right, but I know that we should use the tools
>>> Mother Nature gave us, and 0 is at the very heart of our nature. We
>>> don't need a class modeling 0, because the 0 is there, waiting, ready
>>> to be used. It needs no model, just as 1, 2, 3 ... don't need a model.
>>> Programming languages should enable me to declare a method so that I
>>> can say whether or not I'm ready to receive a 0 value or not. There's
>>> nothing special about the 0, except that it is ``to be or not to be."
>>>
>>
>
Re: Re: Cost of Option / Some vs null
Sébastien
2009/11/21 Stepan Koltsov <stepan [dot] koltsov [at] gmail [dot] com>
Re: Re: Cost of Option / Some vs null
On Sat, Nov 21, 2009 at 07:39, Sébastien Bocq wrote:
> It is easier to miss a variable that may be null than to ignore the
> possibility of an empty Option.
There is a simple rule to not forget about nulls ever (we used it successfully):
No variable is allowed to be null unless that is explicitly documented
in code (with comment or annotation).
Like this:
class User {
// all fields are nullable, null means uninitialized
var field1
var field2
var field3
...
}
S.
> The few times I sticked to the old habits of
> using null I got bitten by it so now I stick to Option, I'll worry about
> performance later. Using Option becomes natural once you get used to it.
>
> Sébastien
>
> 2009/11/21 Stepan Koltsov
>>
>> You probably missed parts of the discussion where explained how Option
>> changes NullPointerException to NoSuchElementException.
>>
>>
>> S.
>
>
Re: Re: Cost of Option / Some vs null
1. It's pervasive in most imperative languages because it's not encoded in types
2. It's semantically ambiguous
#2 is the more interesting one, because it can apply to Option as well, depending on how Option is used. I think of Option as a collection that can contain 0..1 objects, with either being completely valid. However there's nothing to stop people from using the None side to mean "not initialized yet," "unknown," or "an error occurred." I personally think such usage is wrong, and instead types that reflect the intended semantics should be used.
I think arguments about avoiding NPEs by using Option instead of null are red herrings, because you can just as easily call get() on Option and receive a NoSuchElementException (I think that's what it throws).
On Fri, Nov 20, 2009 at 3:50 PM, Stepan Koltsov <stepan [dot] koltsov [at] gmail [dot] com> wrote:
--
http://erikengbrecht.blogspot.com/
Re: Re: Cost of Option / Some vs null
On Sat, Nov 21, 2009 at 03:16, Erik Engbrecht wrote:
> In my opinion null has two big problems:
> 1. It's pervasive in most imperative languages because it's not encoded in
> types
Explain, please.
> 2. It's semantically ambiguous
>
> #2 is the more interesting one, because it can apply to Option as well,
> depending on how Option is used. I think of Option as a collection that can
> contain 0..1 objects, with either being completely valid. However there's
> nothing to stop people from using the None side to mean "not initialized
> yet," "unknown," or "an error occurred." I personally think such usage is
> wrong, and instead types that reflect the intended semantics should be used.
Your comment is great, but I don't think it is a problem.
> I think arguments about avoiding NPEs by using Option instead of null are
> red herrings, because you can just as easily call get() on Option and
> receive a NoSuchElementException (I think that's what it throws).
Yes!
S.
> On Fri, Nov 20, 2009 at 3:50 PM, Stepan Koltsov
> wrote:
>>
>> On Fri, Nov 20, 2009 at 18:58, Paolo Losi wrote:
>> > Philip Köster wrote:
>> >>
>> >> As Scott Meyers wrote in his unforgettable book, ``More Effective C++,"
>> >> he
>> >> left no doubt about his basic point: If you want to express something,
>> >> express it in the language so anyone can understand it. For me that was
>> >> the
>> >> most fundamental sentence of his books. Transferred to Java, which has
>> >> only
>> >> a very poor understanding of constness, this means: ``If you want to
>> >> express
>> >> something as being null, then make it null and not have it an instance
>> >> of a
>> >> contrived made-up class."
>> >
>> > Philip,
>> >
>> > just to provide you with some more context...
>> >
>> >
>> > http://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mi...
>>
>> Blaming null is a common misconception. Bad programmers always make
>> bugs, not depending of whether null exists.
>>
>> I'm confortable with null. In most cases I use Option, but in rare
>> cases nulls are necessary.
>>
>> Example, when class maps database table with tens of columns:
>>
>> ===
>> class User {
>> // null means "uninitialized"
>> var field1: String = null
>> var field2: String = null
>> var field3: String = null
>> var field4: String = null
>> // ...
>> }
>> ===
>>
>> Different subsets of fields are initialized in different queries.
>>
>> ===
>> def findLoginAndEmail(id: Long): User
>> def findBasicFields(id: Long): User
>> def findAllFields(id: Long): User
>> ===
>>
>> Making all fields Options makes access to these fields verbose:
>> "user.field3.get" instead of just "user.field3", "user.field3 =
>> Some(...)" instead of "user.field3 = ...".
>>
>> This design is not perfect, but sometime it is necessary.
>>
>>
>> The main reason why people blame null is bad performance of Option.
>> But if Option is slow (it is), then JVM should be fixed (by
>> introducing value types), not Scala language.
Re: Re: Cost of Option / Some vs null
In Scala I think it's considered bad style to use null in public ways, and ok to use it as an optimization so long as it is restricted to the private parts of your class. In Java null is used all the time, usually to mean either None or to mean "not yet initialized." So with pure Scala code written by a trusted genious you can safely assume that null isn't going to bite you, while with Java you have to be prepared for it all the time.
On Fri, Nov 20, 2009 at 7:27 PM, Stepan Koltsov <stepan [dot] koltsov [at] gmail [dot] com> wrote:
--
http://erikengbrecht.blogspot.com/
Re: Re: Cost of Option / Some vs null
You should include values in your constructor. I believe you can even use immutable classes with hibernate. In fact, I've debated with myself over whether this would help resolve NPE bugs in my codebase. Some developers are too comfortable with null....
- Josh
On Fri, Nov 20, 2009 at 3:50 PM, Stepan Koltsov <stepan [dot] koltsov [at] gmail [dot] com> wrote:
Re: Re: Cost of Option / Some vs null
On Sat, Nov 21, 2009 at 03:01, Josh Suereth wrote:
> Your class is still "wrong".
It solved given task well. So I don't think it is wrong.
> You've chosen the wrong database ORM
> mapper.... (If I wanted to make a dumb point).
You definitely know all my project requirements.
> You should include values in your constructor.
Maybe. But still some fields must remain uninitialized (== null).
> I believe you can even use
> immutable classes with hibernate.
We do not use ORM for number of reasons.
> In fact, I've debated with myself over
> whether this would help resolve NPE bugs in my codebase. Some developers
> are too comfortable with null....
Some people think, that Option is a silver bullet, but actually there
is no difference. If you change null to None, your NPEs get changed to
NoSuchElementException. NPEs weren't problems in our project at all.
Code should just be clear, where nulls are possible.
S.
> - Josh
>
> On Fri, Nov 20, 2009 at 3:50 PM, Stepan Koltsov
> wrote:
>>
>> [snip/]
>>
>> Blaming null is a common misconception. Bad programmers always make
>> bugs, not depending of whether null exists.
>>
>> I'm confortable with null. In most cases I use Option, but in rare
>> cases nulls are necessary.
>>
>> Example, when class maps database table with tens of columns:
>>
>> ===
>> class User {
>> // null means "uninitialized"
>> var field1: String = null
>> var field2: String = null
>> var field3: String = null
>> var field4: String = null
>> // ...
>> }
>> ===
>>
>> Different subsets of fields are initialized in different queries.
>>
>> ===
>> def findLoginAndEmail(id: Long): User
>> def findBasicFields(id: Long): User
>> def findAllFields(id: Long): User
>> ===
>>
>> Making all fields Options makes access to these fields verbose:
>> "user.field3.get" instead of just "user.field3", "user.field3 =
>> Some(...)" instead of "user.field3 = ...".
>>
>> This design is not perfect, but sometime it is necessary.
>>
>>
>> The main reason why people blame null is bad performance of Option.
>> But if Option is slow (it is), then JVM should be fixed (by
>> introducing value types), not Scala language.
>>
>> S.
>
>
Re: Re: Cost of Option / Some vs null
You could make an option that has two states: Unitialized and Initialized(value)e instead.... Especially if you're not using an ORM.
- Josh
On Fri, Nov 20, 2009 at 7:20 PM, Stepan Koltsov <stepan [dot] koltsov [at] gmail [dot] com> wrote:
RE: Cost of Option / Some vs null
> -----Original Message-----
> From: philip [dot] koester [at] web [dot] de [mailto:philip [dot] koester [at] web [dot] de]
> Sent: Friday, November 20, 2009 12:15 PM
> As Scott Meyers wrote in his unforgettable book, ``More
> Effective C++,"
> he left no doubt about his basic point: If you want to
> express something, express it in the language so anyone can
> understand it. For me that was the most fundamental sentence
> of his books. Transferred to Java, which has only a very poor
> understanding of constness, this means:
> ``If you want to express something as being null, then make
> it null and not have it an instance of a contrived made-up class."
Be careful: The premise that a programmer wants "to express something
as being null" may be wrong right to begin with.
I at least would rather want to express something as being an optionally
empty result. This is explicitly expressed in the language when seeing
Option[T] as a result type, and anyone can understand it.
This is NOT expressed when the result type is T and may _implicitly_ be
null or not, what one only detects when looking at the javadoc (just NOT the
language, but an additional textual description!) or my implementation (only
possible for open source).
Beside that:
> > I will not choose to duplicate code for the hypothetical
> developer who will not understand Option.
>
> And I would not want to switch with a developer confronting
> me with such Blödsinn ...
>
I want to state that I am repelled by the tone of the posts of yours
I read in the last time.
Please be so kind to watch your words and keep an adult attitude.
KR
Det
Re: Cost of Option / Some vs null
I will not choose to duplicate code for the hypothetical developer who
will not understand Option.
2009/11/20 Philip Köster :
> As Scott Meyers wrote in his unforgettable book, ``More Effective C++," he
> left no doubt about his basic point: If you want to express something,
> express it in the language so anyone can understand it. For me that was the
> most fundamental sentence of his books. Transferred to Java, which has only
> a very poor understanding of constness, this means: ``If you want to express
> something as being null, then make it null and not have it an instance of a
> contrived made-up class."
>
> Ricky Clarkson schrieb:
>>
>> I introduced Option at work in some Java code for builders; basically,
>> a builder would have a number of parameters, Param,
>> Param, etc. Option would let you have Param> to
>> specify an optional parameter, rather than having to write a separate
>> OptionalParameter class and have code duplication everywhere.
>>
>> Other than that, I said it was a smarter null, as you could not
>> dereference it without being aware that it may contain nothing. I
>> ended up implementing a new Option type in our codebase, though with
>> what I think is an interesting addition; my Option.None contains a
>> String reason. Yes, Tony, this means it's now a String | T, not a
>> Nothing | T, so calling it Option is a little dubious. If every time
>> I got an NPE I could see *why* the value was null at a glance, that'd
>> be excellent. There are far too many return null;s in the codebase;
>> some of them represent errors, some of them represent that there just
>> was no result for some reason.
>>
>> I'm not suggesting Scala's Option changes at all, just detailing an
>> experience.
>>
>> 2009/11/20 Kevin Wright :
>>>
>>> Sometimes this is frustrating hard, because the short answer "Option is a
>>> monad, using nulls is not" is no more enlightening to most Java devs.
>>> I tend to explain it as "Option is a list constrained to size 0 or 1",
>>> this
>>> means that you can use expressions like "for every item in the list" and
>>> know that they still won't error even if the list is empty.
>>>
>>> On Fri, Nov 20, 2009 at 10:36 AM, Philip Köster
>>> wrote:
>>>>
>>>> Ismael Juma schrieb:
>>>>>
>>>>> On Fri, 2009-11-20 at 11:13 +0100, Philip Köster wrote:
>>>>>>
>>>>>> Now this is a good example of how libraries should *not* be designed.
>>>>>> It
>>>>>> places the burden on the user of a lib, who really just wants to get
>>>>>> his job
>>>>>> done and not worry about subleties such as the difference between
>>>>>> `null' and
>>>>>> `None'. This imposes a new kind of fuzzy logic leading to even more
>>>>>> if-then-else branches than we really need.
>>>>>
>>>>> This leads me to think that you're using it wrong. Option is meant to
>>>>> help with the if/else problem that one finds with null (and also the
>>>>> problem that one never knows where null is expected). You may want to
>>>>> check some tutorials on Option and the various ways you can use it
>>>>> without having to rely on if/else all the time.
>>>>>
>>>>> Best,
>>>>> Ismael
>>>>>
>>>>>
>>>> I read all the tutorials, so please don't talk to me like a was a child,
>>>> 'cause that is something that really pisses me off and makes me
>>>> speechless.
>>>> I can very well understand why beginners are confused about the diff
>>>> between
>>>> `Option' and the Java-native null value, and I predict many failures
>>>> will
>>>> arise from this basic misunderstanding. A user asked what the difference
>>>> was, and you gave no answer but only increased the confusedness. QED.
>>>
>>
>>
>>
>
Re: Cost of Option / Some vs null
> I will not choose to duplicate code for the hypothetical developer who
> will not understand Option.
And I would not want to switch with a developer confronting me with such
Blödsinn ...
Re: Cost of Option / Some vs null
Welcome to the new scala-user Ricky :)
Want to lament over a beer?
Philip Köster wrote:
>
>> I will not choose to duplicate code for the hypothetical developer who
>> will not understand Option.
>
> And I would not want to switch with a developer confronting me with
> such Blödsinn ...
>
Re: Cost of Option / Some vs null
Tony Morris schrieb:
> Welcome to the new scala-user Ricky :)
>
> Want to lament over a beer?
>
> Philip Köster wrote:
>>> I will not choose to duplicate code for the hypothetical developer who
>>> will not understand Option.
>> And I would not want to switch with a developer confronting me with
>> such Blödsinn ...
>>
>
No problem on my side. I like Ricky. No insult intended. Drinking a beer
w/ some1 from another continent might broaden my perspective and make my
life more colorful. No hard feelings about Ricky, by no means. I enjoy
his postings, only sometimes I disagree.
Re: Cost of Option / Some vs null
On Fri, 2009-11-20 at 11:36 +0100, Philip Köster wrote:
> I read all the tutorials, so please don't talk to me like a was a child,
I did not. I simply said that if you believe that the usage of Option
leads to more if/else than using null, then maybe you're not using it in
the idiomatic way. I don't see why you'd interpret it the way you did.
> A user asked what the difference was, and you gave no answer but only increased the
> confusedness.
He did not ask that. He was interested in the performance issues of
using Option in tight loops (as I stated in the previous message
already).
Best,
Ismael
Re: Cost of Option / Some vs null
To put it another way if it wouldn't be for Java interoperability I would hope to see scalac abandon null.
Actually it would be awesome if the compiler would actually transform any null value into Option.
And no I do not think that it is as efficient as null since null is basically the absense of any type information. (as far as I understand it) and option is an extra object that wraps a value. But unless you can proof in your case that Option is a bottleneck in your case I wouldn't worry about it and take the safety of Option over null anytime.
Just my 2cts.
2009/11/20 Maxime Lévesque <maxime [dot] levesque [at] gmail [dot] com>