Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 05:03
    scala-jenkins milestoned #9674
  • 05:03
    som-snytt opened #9674
  • 05:02
    retronym labeled #9673
  • 05:01
    retronym review_requested #9673
  • 05:01
    scala-jenkins milestoned #9673
  • 05:01
    retronym opened #9673
  • 01:41
    SethTisue edited #1433
  • 01:40
    SethTisue labeled #1433
  • 01:40
    SethTisue assigned #1433
  • 01:40
    SethTisue opened #1433
  • Jun 18 22:52

    xuwei-k on xuwei-k-patch-1

    (compare)

  • Jun 18 22:52

    xuwei-k on main

    Create CODEOWNERS https://docs… (compare)

  • Jun 18 22:52
    xuwei-k closed #2084
  • Jun 18 20:45
    jacobus commented #1248
  • Jun 18 20:01

    eed3si9n on main

    Update scala-for-java-programme… Merge pull request #2060 from h… (compare)

  • Jun 18 20:01
    eed3si9n closed #2060
  • Jun 18 19:54
    xuwei-k commented #2059
  • Jun 18 19:54
    xuwei-k review_requested #2084
  • Jun 18 19:54
    xuwei-k review_requested #2084
  • Jun 18 19:54
    xuwei-k opened #2084
Abdhesh Kumar
@abdheshkumar

Anyone has an idea how to override common configuration in included configuration that referenced with environment variable? For example, I have common.conf that has all common configurations and local.conf that override common configurations as per local environment.

common.conf

myapp {
    server-address = ${SERVER_HOSTNAME}
    server-port = ${SERVER_PORT}
}
----------------------
local.conf

include "common"
# override default (Common) settings
myapp {
    server-address = "localhost"
    server-port = 9000
}

while loading local.conf. I am getting below error.

 Could not resolve substitution to a value: ${SERVER_HOSTNAME}
jonathan edwards
@_jedw_twitter
does anyone know what the difference between .contain() and .contains() is?
I believe they are a part of scalatest, but when i search for it I can’t find its definition
the context it’s being used is in this line: items => s"find $itemNum in the available list" >> items.map(_.itemNumber).should(contain(itemNum))
Abdhesh Kumar
@abdheshkumar
@_jedw_twitter contains must be inside scalatest Matchers
Vinayak Pathak
@vinayakpathak

I wasted a day struggling with this:

trait Model {
  type State
}

trait Algorithm {
  val model: Model
  type State = model.State

  def infer: State
}

val m: Model = new Model {
  type State = Int
}

val a = new Algorithm {
  val model = m

  def infer = 1
}

This throws an error:

ScalaFiddle.scala:21: error: type mismatch;
 found   : scala.this.Int(1)
 required: $anon.this.State
    (which expands to)  $anon.this.model.State
    def infer = 1
                ^

I stared at the longest time on the definition of val a because that's where the error was coming from, but eventually realized the cause was my definition of val m. If I remove the : Model and make it val m = new Model {...} it works.

Abdhesh Kumar
@abdheshkumar
@_jedw_twitter here you could find more about matchers http://www.scalatest.org/user_guide/using_matchers
Fabio Labella
@SystemFw

If I remove the : Model and make it val m = new Model {...} it works.

yes

when you do : Model you remove the refinement
which is inferred otherwise
it should bem: Model {type State = Int }
Vinayak Pathak
@vinayakpathak
yeah that's interesting
Fabio Labella
@SystemFw
you can look into the Aux pattern as well to see a shorthand
which is very commonly used in the shapeless world
Vinayak Pathak
@vinayakpathak
yeah I've seen the Aux pattern
Fabio Labella
@SystemFw
same thing, m: Model.Aux[Int]
I'd recommend using existentials only when you need them though
Vinayak Pathak
@vinayakpathak
if I had chosen to implement Model as trait Model[State] though, I would've been notified about the error at the line val m: Model = new Model[Int] {...} coz there would be a missing type parameter
Fabio Labella
@SystemFw
well : Model is a valid type there, so there's no error
the error is when you try to unify it with Int later
Vinayak Pathak
@vinayakpathak
ummm why is Model valid
Fabio Labella
@SystemFw
do you need State to be existential there, since you are already making the whole Model existential in Algorithm?
Vinayak Pathak
@vinayakpathak
i'm not sure what existential means
Fabio Labella
@SystemFw

ummm why is Model valid

Because scala allows you to have abstract (existential) types

well, replace that word with "abstract"
scala allows you to have abstract types
Vinayak Pathak
@vinayakpathak
oh i see ok
ok then i'm not sure when one would need a type to be existential as opposed to just a type parameter
Fabio Labella
@SystemFw
the two things, type parameters and abstract types (universals and existentials) are two different ways to enforce information boudaries
jonathan edwards
@_jedw_twitter
@abdheshkumar Thanks man, I guess i wasn’t reading enough of the page.
Fabio Labella
@SystemFw
well, one use case is to hide the specific type used there
for example, imagine List[Algorithm]
Vinayak Pathak
@vinayakpathak
i see
Fabio Labella
@SystemFw
assume that each algorithm has an input, output and internal state
and the in-out is the only thing that matters from the outside
if you had Algorithm[State] you woudn't be able to put them in a List with a proper type
Vinayak Pathak
@vinayakpathak
hmm i see
Fabio Labella
@SystemFw
but since in my hypothetical example the State is purely internal, you hide it by making it existential
in this case through an abstract type
does that make any sense?
Vinayak Pathak
@vinayakpathak
ok got it
yeah
Fabio Labella
@SystemFw
cool
Vinayak Pathak
@vinayakpathak
but is it an aesthetic thing or do their exist things we couldn't do if existential types didn't exist
Fabio Labella
@SystemFw
that's a really good question
the answer is not that simple unfortunately
you need to distinguish between existential and universal types as a general concept (e.g. in type theory), and the programming language features that encode them
but in short, no, it's not an aesthetic thing
Vinayak Pathak
@vinayakpathak
ahh so universal type being another name for type parameters?
it sort of makes sense... coz when you define trait MyTrait[T] you're saying MyTrait[T] exists for every T but if you say trait MyTrait {type T} you're making no such guarantees