- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
Why there is no implicity "toOption" conversion defined?
Tue, 2010-04-27, 22:49
Hi!
Is there any good reason for not having an implicit "toOption" defined in Scala?
Like, if I define
def fn(x: Option[Int]) = {...}
and then call
fn(1)
this would be implicitly converted to
fn(Some(1))
Just curious.
Thanks in advance.
--
Knowledge is power.
Power corrupts.
Study hard.
Be evil.
"You question the worthiness of my Code? I should kill you where you stand!"
Is there any good reason for not having an implicit "toOption" defined in Scala?
Like, if I define
def fn(x: Option[Int]) = {...}
and then call
fn(1)
this would be implicitly converted to
fn(Some(1))
Just curious.
Thanks in advance.
--
Knowledge is power.
Power corrupts.
Study hard.
Be evil.
"You question the worthiness of my Code? I should kill you where you stand!"
Wed, 2010-04-28, 09:17
#2
Re: Why there is no implicity "toOption" conversion defined?
Jefferson Andrade wrote:
> Hi!
>
> Is there any good reason for not having an implicit "toOption" defined
> in Scala?
>
> Like, if I define
>
> def fn(x: Option[Int]) = {...}
>
> and then call
>
> fn(1)
>
> this would be implicitly converted to
>
> fn(Some(1))
>
>
> Just curious.
>
> Thanks in advance.
>
>
Wed, 2010-04-28, 11:57
#3
Re: Why there is no implicity "toOption" conversion defined?
wouldn't that convert null to Some(null)?
-------- Original-Nachricht --------
> Datum: Wed, 28 Apr 2010 18:09:38 +1000
> Von: Tony Morris
> An: Jefferson Andrade
> CC: scala-user@listes.epfl.ch
> Betreff: Re: [scala-user] Why there is no implicity "toOption" conversion defined?
> Jefferson Andrade wrote:
> > Hi!
> >
> > Is there any good reason for not having an implicit "toOption" defined
> > in Scala?
> >
> > Like, if I define
> >
> > def fn(x: Option[Int]) = {...}
> >
> > and then call
> >
> > fn(1)
> >
> > this would be implicitly converted to
> >
> > fn(Some(1))
> >
> >
> > Just curious.
> >
> > Thanks in advance.
> >
> >
> > --
> > Knowledge is power.
> > Power corrupts.
> > Study hard.
> > Be evil.
> >
> > "You question the worthiness of my Code? I should kill you where you
> > stand!"
> >
> It would be poor form to do this with an implicit.
>
> Perhaps, why is there no generalisation of a pointed functor?
>
> trait Pointed[P[_]] {
> def point[A](a: => A): P[A]
> }
>
Wed, 2010-04-28, 12:17
#4
Re: Why there is no implicity "toOption" conversion defined?
For extra fun, add collections into the mix!
For example: null, None and Some(null) all have subtly different meanings when attempting to retrieve an element from a list.
Remember that for some collection types it's perfectly valid to insert null as an element. Even if this were restricted for pure Scala collections, there's still the interop issue of handling collections supplied by java code.
On 28 April 2010 11:49, Dennis Haupt <h-star@gmx.de> wrote:
--
Kevin Wright
mail/google talk: kev.lee.wright@googlemail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda
For example: null, None and Some(null) all have subtly different meanings when attempting to retrieve an element from a list.
Remember that for some collection types it's perfectly valid to insert null as an element. Even if this were restricted for pure Scala collections, there's still the interop issue of handling collections supplied by java code.
On 28 April 2010 11:49, Dennis Haupt <h-star@gmx.de> wrote:
wouldn't that convert null to Some(null)?
-------- Original-Nachricht --------
> Datum: Wed, 28 Apr 2010 18:09:38 +1000
> Von: Tony Morris <tonymorris@gmail.com>
> An: Jefferson Andrade <joandrade@gmail.com>
> CC: scala-user@listes.epfl.ch
> Betreff: Re: [scala-user] Why there is no implicity "toOption" conversion defined?
> Jefferson Andrade wrote:
> > Hi!
> >
> > Is there any good reason for not having an implicit "toOption" defined
> > in Scala?
> >
> > Like, if I define
> >
> > def fn(x: Option[Int]) = {...}
> >
> > and then call
> >
> > fn(1)
> >
> > this would be implicitly converted to
> >
> > fn(Some(1))
> >
> >
> > Just curious.
> >
> > Thanks in advance.
> >
> >
> > --
> > Knowledge is power.
> > Power corrupts.
> > Study hard.
> > Be evil.
> >
> > "You question the worthiness of my Code? I should kill you where you
> > stand!"
> >
> It would be poor form to do this with an implicit.
>
> Perhaps, why is there no generalisation of a pointed functor?
>
> trait Pointed[P[_]] {
> def point[A](a: => A): P[A]
> }
>
> --
> Tony Morris
> http://tmorris.net/
>
--
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
--
Kevin Wright
mail/google talk: kev.lee.wright@googlemail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda
On Tue, Apr 27, 2010 at 06:49:48PM -0300, Jefferson Andrade wrote:
> Is there any good reason for not having an implicit "toOption" defined
> in Scala?
Implicits have consequences. The relevant question is whether there is
any good reason to have such a thing. And the answer is no, because we
like types and don't toss them around willy-nilly on a global basis.
But, unrelatedly, what we DO need globally is THIS implicit.
implicit def u2o(x: Unit) = None
Just imagine the typing savings!
scala> var x: Option[Int] = ()
x: Option[Int] = None
OK, I'm just kidding. But look, a use case for being able to end a
block in a definition (which you can do in 2.8 but couldn't in 2.7.)
scala> def f[T] : Option[T] = { implicit def u2o(x: Unit) = None }
f: [T]Option[T]
As far as I can think of, the only way to take legitimate advantage of a
block whose final statement is a def is to have the def be an implicit
which acts on the () which the compiler subsequently inserts.