Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Przemek Sokół
    @falconepl
    That's because both key and secret are strings - so they have the same, general type while they mean different things. You should wrap key and secret in separate value classes or tag them with Tagged

    So you should have:

    case class Key(value: String) extends AnyVal
    case class Secret(value: String) extends AnyVal
    class BasicCredentials(key: Key, secret: Secret)

    or:

    trait Key
    trait Secret
    class BasicCredentials(key: String @@ Key, secret: String @@ Secret)
    Jinto Thomas
    @ttj4
    Thank you! @falconepl. Also could you please suggest if I should use the factory method to load say typesafe Config's? So there are some java static methods which return a class
    for example ConfigFactory.parseResource("somefile") returns a Config
    Przemek Sokół
    @falconepl
    Check out PureConfig library - https://pureconfig.github.io/
    It will allow you to get your configuration as an instance of some Config class, based on e.g. your application.conf content
    Jinto Thomas
    @ttj4
    Actually I am not exactly looking for config's alone. It was more like an example. Actually I am not clear how to do the wiring if I have a factory method (scala objects which returns a class instance or some java static method which returns a class instance
    This is from the example, is it restricted to companion objects alone?
    class A()
    
    class C(a: A, specialValue: Int)
    object C {
      def create(a: A) = new C(a, 42)
    }
    
    trait MyModule {
      lazy val a = wire[A]
      lazy val c = wireWith(C.create _)
    }
    Przemek Sokół
    @falconepl
    Sorry, I've misunderstood your question. I think that with wireWith you should be able to reference any object's method that returns some T instance, as long as Macwire is able to fill in all the arguments required by that method. So if we talking about some Java static method, it's almost certain that it would require some primitive types. If it does, I would suggest calling that method by hand and bring it to Macwire's scope instead:
    case class B(dependency: T)
    lazy val a: T = someJavaLibMethod(...)
    lazy val b = wire[B]
    Jinto Thomas
    @ttj4
    @falconepl Thank you! I was under the impression it's some sort of anti-pattern to call someJavaLibMethod directly
    Jinto Thomas
    @ttj4

    Hello everyone, I am trying to use wireWith with a factory method which accepts multiple parameters.

    class A
    class B
    class C
    
    object D {
      def bind(a: A, b: B) : C = new C
    }
    
    trait MyTrait {
      import com.softwaremill.macwire._
    
      lazy val a = wire[A]
      lazy val b = wire[B]
      lazy val c = wireWith(D.bind(a, _))
    }

    but I am getting missing parameter type for expanded function ((x$1) => D.bind(a, x$1)) lazy val c = wireWith(D.bind(a, _)).

    Kai
    @neko-kai
    @jinto-thomas Annotate it with B as in wireWith(D.bind(a, _: B))
    Artem Egorkine
    @arteme
    I have a play project that I'm converting from cake to macwire and everything went rather smooth, except... I wire the controllers and it goes all just fine, except for one it will complain recursive lazy value indexController needs type. I can rewrite the lazy val indexController = wire[IndexController] as manual instantiation, lazy val indexController = new IndexController(...), which works, but not the wire-variant. How do I go about debugging this?
    Wojtek Pituła
    @Krever
    @arteme Have you tried putting type ascription to the value as the error suggests?
    Artem Egorkine
    @arteme
    @Krever yes, it compiles, but I get an UinitializedFieldError at run-time
    Wojtek Pituła
    @Krever
    this sounds like recursive value indeed. Do you have field of type IndexController as a constructor parameter to IndexController?
    Artem Egorkine
    @arteme
    I found macwire.debug property, but i don't see anything immediately wrong with what macwire does. Starting to look with suspicion in the direction of the compiler itself ;)
    @Krever That's what I thought, but no, the only reference to IndexController is from the router
    Artem Egorkine
    @arteme
    @Krever okay, I figured it out. the "recursive value needs type error" is just telling me that I can't do val indexController = wire[IndexController]; do_stuff(indexController). Why, doesn't the compiler infer the type? and UinitializedFieldError was not related to wiring at all
    Artem Egorkine
    @arteme
    Is there a way to use macwire in a generic function? I basically need a factory that needs to wire the object and then call some methods on it... I was hoping I could do something like:
      def specialWire[T <: CtrlBase]: T = {
        val t: T = wire[T]
        // ... do something to t ...
        t
      }
    Adam Warski
    @adamw
    @arteme sorry, no, the T must be fully statically known at compile time
    Kai
    @neko-kai
    @arteme You can write a macro to summon functions generated by wire with implicits, or you can switch to distage which supports this directly:
      import distage.constructors.ClassConstructor
    
      def specialWire[T <: CtrlBase: ClassConstructor] = {
        ClassConstructor[T].map {
          t => 
          // ... do something to t ...
        }
      }
    Artem Egorkine
    @arteme
    @neko-kai : Thanks. Distage looks interesting, but too complicated for my use-case. I ended up just rewriting my code as do_something(wire[...]) for every CtrlBase sub-class instance I wire...
    Antoine Doeraene
    @sherpal
    Hello! I'm starting to use macwire with play framework (and actually zio). When I compile everything works out great, but when I use the dist command to package the app, there are dependencies which it doesn't find. Typically it fails with Cannot find a value of type: [zio.Runtime[services.models.usersdao.UsersDAO]] (which leads me to believe it's more of a problem with ZIO rather than play or the sbt-native-packager. Did you encounter something like this already? Thanks! (I'm using play 2.8 and scala 2.13)
    6 replies