[WIP] exposing RedisEnvironment via environment

[m-kalai]

• another approach to pushing codec and executor dependency from RedisCommand creation to it's execution

[mijicd]

A few minor comments from my side, but we have a bigger problem, which is that RedisEnvironment (or BinaryCodec with RedisExecutor) leaks in user-land, thus going against the service pattern and the changes you did in #727.

[mijicd]

Well, you may as well remove the RedisLive object and pack everything in Redis, e.g.:

object Redis {
  lazy val layer: ULayer[Redis] = ZLayer.succeed(new Redis)
}

In the future we may consider renaming it to live, perhaps it'll be more consistent with the ecosystem.

[mijicd]

Super nitpick:

Suggested change

	lazy val layer = ZLayer {
	for {
	codec <- ZIO.service[BinaryCodec]
	executor <- ZIO.service[RedisExecutor]
	} yield new RedisEnvironment(codec, executor)
	}
	lazy val layer =
	ZLayer {
	for {
	codec <- ZIO.service[BinaryCodec]
	executor <- ZIO.service[RedisExecutor]
	} yield new RedisEnvironment(codec, executor)
	}

[mijicd]

I'm wondering if this should be private at all now that it's a part of all commands. In fact, I'm thinking if it would be wise to replace it with BinaryCodec with RedisExecutor.

[m-kalai]

A few minor comments from my side, but we have a bigger problem, which is that RedisEnvironment (or BinaryCodec with RedisExecutor) leaks in user-land, thus going against the service pattern and the changes you did in #727.

yes you're right, i was just thinking that maybe it's ok to expose codec and executor to user. saw some libs doing that, but yes it doesn't play well with service pattern.

to follow service pattern exactly, we should move implementation of commands from trait to some class and pass codec and executor as constructor params. if we don't want to mix codec and executor into Redis trait, or expose them to the user via environment, or depend on use of implicits, there is probably no other way. or we can just leave it as is.