Quick scala question (found in lift/framework)

[Diego Medina]

Hi,

I have seen code like this a few times:

def get: T = synchronized {
value match {
case Full(v) => v
case _ => value = Full(f)
value.open_!
}
}


is there any reason why this would not do the same:

def get: T = synchronized {
value match {
case Full(v) => v
case _ => value = Full(f)
f
}
}

Note how instead of opening the Full box we just assigned, I return f,
which is the value inside the box

Thanks

Diego

--
Diego Medina
Lift/Scala Developer
di...@fmpwizard.com
http://www.fmpwizard.com

[Aditya Vishwakarma]

Some others ways of doing this:

1)value openOr { value = Full(f);f } 

2) value = value or Full(f)

then value.open_! or f.

My scala fu isn't awesome enough to know which is better, except that I know pattern matching on Boxes/Options is slow. The only way to know which method is better is by looking at the bytecode generated.

Aditya Vishwakarma

--
--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

[Maarten Koopmans]

Hi,

Looks fine to me. It obviously is better than using open_! Have you tested both against dangerous (e.g. null) values?

--Maarten

[David Pollak]

On Wed, Oct 17, 2012 at 10:17 PM, Diego Medina <di...@fmpwizard.com> wrote:

Hi,

I have seen code like this a few times:

  def get: T = synchronized {
    value match {
      case Full(v) => v
      case _ => value = Full(f)
      value.open_!
    }
  }


is there any reason why this would not do the same:

  def get: T = synchronized {
    value match {
      case Full(v) => v
      case _ => value = Full(f)
      f
    }
  }

Yeah... this works.

The reason that I use pattern matching in code like this is to avoid the creation of a closure/function. The function may or may not be inlined by HotSpot, but in the case of a simple pattern match/extraction, I think the performance is better.

 

Note how instead of opening the Full box we just assigned, I return f,
which is the value inside the box

Thanks

  Diego

--
Diego Medina
Lift/Scala Developer
di...@fmpwizard.com
http://www.fmpwizard.com

--
--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

--

Telegram, Simply Beautiful CMS https://telegr.am

Lift, the simply functional web framework http://liftweb.net

Follow me: http://twitter.com/dpp
Blog: http://goodstuff.im

[Diego Medina]

Thanks everyone for your answers.

Diego

[Naftoli Gugenheim]

On Thu, Oct 18, 2012 at 11:12 AM, David Pollak <feeder.of...@gmail.com> wrote:

On Wed, Oct 17, 2012 at 10:17 PM, Diego Medina <di...@fmpwizard.com> wrote:

Hi,

I have seen code like this a few times:

  def get: T = synchronized {
    value match {
      case Full(v) => v
      case _ => value = Full(f)
      value.open_!
    }
  }


is there any reason why this would not do the same:

  def get: T = synchronized {
    value match {
      case Full(v) => v
      case _ => value = Full(f)
      f
    }
  }

Yeah... this works.

The reason that I use pattern matching in code like this is to avoid the creation of a closure/function. The function may or may not be inlined by HotSpot, but in the case of a simple pattern match/extraction, I think the performance is better.

Plus fewer classes to store and load.

[Jeppe Nejsum Madsen]

Diego Medina <di...@fmpwizard.com> writes:

> Hi,
>
> I have seen code like this a few times:
>
> def get: T = synchronized {
> value match {
> case Full(v) => v
> case _ => value = Full(f)
> value.open_!
> }
> }
>
>
> is there any reason why this would not do the same:
>
> def get: T = synchronized {
> value match {
> case Full(v) => v
> case _ => value = Full(f)
> f
> }
> }
>
> Note how instead of opening the Full box we just assigned, I return f,
> which is the value inside the box

Depends on the f. If it's a function it will be evalauted twice (which
may be expensive)

/Jeppe

[Diego Medina]

> Depends on the f. If it's a function it will be evalauted twice (which
> may be expensive)

More than expensive, it actually made a mongodb test fail.

It took me a few hours of tracking down which change was causing this
one mongodb test to fail, it was one where encrypting the password did
not result in the correct encryption. I had to go and undo one file at
the time to see where the problem was, and once I changed the code in
FatLazy.scala to:

def get: T = synchronized {
value match {
case Full(v) => v
case _ => value = Full(f)

value.openOrThrowException("We just checked that this is a Full box.")
}
}

then the test passed again.

For the record, the test that was failing was:

[info] MongoRecordExamples Specification
[info]
[error] x TstRecord example
[error] the value is not equal to 'true' (MongoRecordExamplesSpec.scala:289)
[info] + Ref example
[info] + List example
[info] + Map Example
[info] + Optional Example
[info] + Strict Example
[info]
[info] Total for specification MongoRecordExamples Specification

and the code in FatLazy that made it fail was:

def get: T = synchronized {
value match {
case Full(v) => v
case _ => value = Full(f)
f
}
}

Thanks,

Diego


>
> /Jeppe

>
> --
> --
> Lift, the simply functional web framework: http://liftweb.net
> Code: http://github.com/lift
> Discussion: http://groups.google.com/group/liftweb
> Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code
>
>
>