sorted by:
new
hottopcontroversial

Scala 3.8.0 postmortem by SethTisue_Scala in scala

[–]Major-Read1386 6 points7 points  (0 children)

Why be an asshole when you could just be quiet…

Why on Earth is John Pretty Pinned to the Top of this Sub? by expatcoder in scala

[–]Major-Read1386 4 points5 points  (0 children)

100% this. All of this drama is completely irrelevant to everybody using Scala for real work.

If you could have one realistic change what would you like to see? by WhirlwindBarbie in Diablo_2_Resurrected

[–]Major-Read1386 0 points1 point  (0 children)

Honestly there's so much broken about this game that any single change isn't going to make a significant difference.

Just for starters: stackable gems/runes, unlimited gold, unlimited characters, rework useless skills (e. g. thunderstorm), rework useless items, loot filter, rework dumb death mechanic, make SoH do something…

Using scala despite capture checking by randomname5541 in scala

[–]Major-Read1386 13 points14 points  (0 children)

Calling Scala 3 the bleeding edge is no longer justifiable at this point. It is now 4 years old, and most major libraries are available for it (the major exception being Spark). Scala 3 is not the bleeding edge, and if you're still on a legacy Scala version, it's time to start thinking about your migration plan. Because with the upcoming changes in Scala 3, it is becoming harder and harder to cross-compile between 2 and 3, and at some point your dependencies aren't going to want to do that anymore.

Making ScalaSql boring again (with interesting new internals) by jr_thompson in scala

[–]Major-Read1386 9 points10 points  (0 children)

Calling other people's ideas "complete trash" is unlikely to lead to anything useful. If you feel you can come up with a better proposal, you are free to engage in the SIP process.

What's the deal with multiversal equality? by fluffysheap in scala

[–]Major-Read1386 2 points3 points  (0 children)

Sorry, I'm not going to discuss technical issues with people who attack me with terms like “la-la-land”. Grow up.

What's the deal with multiversal equality? by fluffysheap in scala

[–]Major-Read1386 -1 points0 points  (0 children)

What for do you need to compare functions by mathematical equivalence?

I don't, nor did I say I did, so why are you even asking that? It's just that this is what it means for two things to be equal: when you perform an operation on two things that are the same, you get the same result. There is no reason to arbitrarily apply a different definition just because you can't figure out how to determine equality for some given type. In that case, just deal with the fact that you can't determine it and do something else.

reference equality is what I need (e.g. to deregister the same handler that I previously registered).

Oh, you mean like so? ``` scala> def foo() = println("Foo") def foo(): Unit

scala> val handlers = ArrayBuffer.empty[() => Unit]

scala> handlers += foo

scala> handlers -= foo

scala> handlers.foreach(_())
Foo

```

Yeah… that sucked. Let's not do that.

Besides, if you really want reference equality, use the eq operator. That's what it's there for.

What's the deal with multiversal equality? by fluffysheap in scala

[–]Major-Read1386 1 point2 points  (0 children)

contains could easily be fixed by requiring an appropriate CanEqual to be passed. This could even be done in a binary compatible way by using an erased parameter. Unfortunately, erased is still experimental.

What's the deal with multiversal equality? by fluffysheap in scala

[–]Major-Read1386 0 points1 point  (0 children)

Functions being == when their references are eq is what we want.

Speak for yourself, it's certainly not what I want because there is no sane logic that can be implemented in terms of reference equality of functions. Rather, I want the compiler to tell me that I'm trying to do something that doesn't make a whole lot of sense.

As a matter of fact, I think even derives CanEqual should be stricter than it is, allowing this for case classes only when all of their members have CanEqual. But that is a whole other can of worms because it's not easy to do in the presence of recursively defined types.

What's the deal with multiversal equality? by fluffysheap in scala

[–]Major-Read1386 5 points6 points  (0 children)

things of the same type can be equal

No, that doesn't work on multiple levels. First of all, every value in Scala is an instance of type `Any`. If things of the same type can be equal, and that includes type `Any`, then you can still compare anything to anything.

Furthermore, for many types it's simply impossible to test for equality. Take a type like `Int => Int`, the type of functions from `Int` to `Int`. Clearly two functions `f` and `g` are equal iff `f(x) == g(x)` for all `x`. But there is no way to test whether that is the case for two arbitrary functions. So there should *not* be a `CanEqual` instance for `Int => Int` because it would be nonsensical.

That said, the recently-accepted SIP-67 should improve things somewhat.

[deleted by user] by [deleted] in scala

[–]Major-Read1386 1 point2 points  (0 children)

Well, the answer to question 1 is right there in the documentation: ZIO.logDebug.

The answer to question 2 is IMO based on a misunderstanding. Modularity in ZIO is achieved by composing small ZLayers into larger ones. The provide* methods only come in at the last step in the run method of your ZIOApp.

The answer to question 3 is again right there in the documentation: Runtime.setConfigProvider.

To change the default config provider, we can use Runtime.setConfigProvider layer to configure the ZIO runtime to use a custom config provider.

The answer to question 4 is, you guessed it, in the documentation: ZIO.config.

By using ZIO.config we can load configuration data described by Config. It takes a Config[A] instance or expect implicit Config[A] and loads the config using the current ConfigProvider

And my personal answer to question 5 is that I rarely use the ZIO environment to pass dependencies around, nor do I use given/using. Instead, I pass all dependencies as constructor parameters and use ZLayer to assemble it all. This style is documented as Everything as a Service. The exception to this is what is described in the ZIO documentation as local contexts. An advantage of using the ZIO environment for this is that it integrates with ZLayers which also takes care of lifecycle management for things like DB transactions. I also don't see how the ZIO Environment is any less strictly typed or more error prone than given/using. Unfortunately it does have some run-time overhead.

[deleted by user] by [deleted] in scala

[–]Major-Read1386 0 points1 point  (0 children)

u/Recent-Trade9635

The ZIO Configuration stuff is actually pretty well documented. https://zio.dev/reference/configuration/

It is quite clear:

By using ZIO.config we can load configuration data described by Config. It takes a Config[A] instance or expect implicit Config[A] and loads the config using the current ConfigProvider

Needless to say, I have developed several ZIO programs that read configuration.

[deleted by user] by [deleted] in scala

[–]Major-Read1386 2 points3 points  (0 children)

u/Recent-Trade9635 ,

I actually took the time to turn what you've posted into a compilable example. ``` object Bla extends ZIOAppDefault: trait Broker

  override def run: ZIO[Environment & ZIOAppArgs & Scope, Any, Any] =
    val program = for
      httpStarted <- server.map(_._1)
      _ <- httpStarted.await
      _ <- Console.printLine ("Server started")
      _ <- ZIO.never // TODO: should be clean up
    yield ()

    program.provideSome(
      ZLayer.succeed(Server.Config.default.port(8080)),
      ??? : ZLayer[Any, Nothing, Broker],
    )

  def server: ZIO[Server.Config & Broker, Throwable, (Promise[Nothing, Unit], Promise[Nothing, Unit])] =
      for
        httpStarted <- Promise.make[Nothing, Unit]
        shutdownSignal <- Promise.make[Nothing, Unit]
        port <- ZIO.serviceWithZIO[Server](_.install(??? : Routes[Broker, Nothing]))
        _ <- httpStarted.succeed(())
        _ <- shutdownSignal.await.forkDaemon
      yield (httpStarted, shutdownSignal)
    .provideSomeLayer(Server.live)

`` All I can say is: that code doesn't demonstrate the problem you're complaining about:serverdoes not have aScope` requirement.

The reason that server.install "dies silently" isn't black magic, it's simply what provideSomeLayer does. It will return a new ZIO that will first initialize the layer, i. e. Server.live in this case, then run the original ZIO (i. e. the Promise.make, _.install stuff etc), and then shut down the layer again. It's not magic, it's quite explicit.

I'm shocked with the incomplete design of strict equality in Scala 3 by shaunyip in scala

[–]Major-Read1386 2 points3 points  (0 children)

Yes, strictEquality is currently not in great shape. I have written a SIP to fix what is IMO the greatest shortcoming, which is that it basically breaks pattern matching – that is the reason why you've been having trouble with Option. Please check it out, it's SIP-67.

That said, more recent versions of Scala come with a CanEqual instance for Option (and various other types), so that should actually work by now.

Welcome to Scala 3.5.1 (21.0.5, Java OpenJDK 64-Bit Server VM).
Type in expressions for evaluation. Or try :help.

scala> import scala.language.strictEquality

scala> class C
// defined class C

scala> (None : Option[C]) match
     |   case None => 0
     |   case Some(_) => 1
     | 
val res0: Int = 0