Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Stevo Slavić
    @sslavic
    is there any support for other module lifecycle events, like close?
    Adam Warski
    @adamw
    no, you'd have to do it yourself
    as there's no container the module doesn't really have any "managed" lifecycle beyond creation :)
    but you could e.g. add a close() method to your module and there do any cleanup
    Stevo Slavić
    @sslavic
    ok, clear, thanks
    maybe a macro or something is possible
    which I could use in close method of a module
    which would inspect all vars of module, and ones which implement e.g. AutoClosable, code would be generated that calls close on them
    and respect order of instantiation, to call close in reverse order
    Adam Warski
    @adamw
    yeah more generally something that returns a set/list of all members that are a subtype of a given type
    I think there's an issue for that ...
    quite old even :) #8
    Stevo Slavić
    @sslavic
    cool
    could filter, and map in close
    foreach
    for each AutoClosable, call close
    but without this order constraint, that they get closed inverse to order of instantiation
    Adam Warski
    @adamw
    that could be tricky
    to get the order of instantiation
    and what about a method
    registerForClosing(t: T): T
    in which all values which require closing would have to be wrapped
    that would capture the correct order
    the registerForClosing would add the instance to a list and return it unmodified
    Stevo Slavić
    @sslavic
    wire macro could generate those registerForClosing calls automatically, given condition is met that object is a subtype of AutoClosable
    Adam Warski
    @adamw
    true :)
    Yves Müller
    @slomo
    I have usecase question for the wire macro. Most of my Compontents take configuration options (eg. Database name) and other components (eg. Excution context) as a parameter. Now I'd like to use wire in order to provide the components but not the configuration options. Is that even possible?
    My rational is that most of the config options are Strings so that would require to tag them all ... which would result in basically writing down a copy of the config file it self mapping all the paths in the config like "system1.database.name" to tags like "System1DatabaseName"
    Or is there maybe an other way to avoid this? (Maybe a integration with typesafe config to automatically tag values?)
    Adam Warski
    @adamw
    @slomo that's a very good question and I think currently it's not supported. The main problem is that you would like to have some parameters of a component automatically wired, and this causes two issues:
    1. how would you determine which parameters should be provided automatically, and which should be provided by hand?
    2. how would you provide the parameters which a have to provided manually? preferrably in an IDE-friendly way?
    This message was deleted
    integration with typesafe-config would be possible for sure ... maybe something like this:
    • there should be a single dependency of type Config available
    • any parameters marked with with a config path (*) would be looked up in the config
    now there's the question on how you would mark those parameters - with an annotation? but then, what about e.g. default values? any ideas? :)
    Michael McFarland
    @mikedmcfarland

    I'm a little surprised by the following behavior
    given a type PlatformsPage with dependencies

    class PlatformsPage(platformStore:PlatformStore,platformBackend:(BackendScope[Props,State] => Backend))

    I'm trying to create a factory method (platformsBackend) as a def.

    trait PlatformsModule {
      lazy val platformsPage = wire[PlatformsPage]
      lazy val platformsStore = wire[PlatformStore]
      def platformsBackend(scope:BackendScope[Props,State]):Backend = new Backend(scope)
    }

    This results in an error:

    Cannot find a value of type: [japgolly.scalajs.react.BackendScope[spatutorial.client.modules.platform.Props,spatutorial.client.modules.platform.State] => spatutorial.client.modules.platform.Backend]

    however these versions work

    lazy val platformsBackend:BackendScope[Props,State] => Backend = new Backend(_)
    type BackendFactory = BackendScope[Props,State] => Backend
    lazy val platformsBackend:BackendFactory = new Backend(_)

    can function defs not be used to create factory dependencies?

    Sorry if that's clearly stated, or I'm missing something obvious. Macwire has been a joy to use
    Adam Warski
    @adamw
    defs aren't currently automatically converted to function values, but that would be definitely a good feature to add - could you create a GH issue?
    Michael McFarland
    @mikedmcfarland
    Sure, adamw/macwire#43
    Adam Warski
    @adamw
    Thanks :)
    Steven Heidel
    @stevenheidel
    Is there any reason why the latest versions weren't released for Scala 2.10?
    Adam Warski
    @adamw
    no, I think nobody simply updated the scala-2.10 branch :)
    Steven Heidel
    @stevenheidel
    How much work do you think that would be?
    Adam Warski
    @adamw
    I suspect not much, there are some differences in 2.10 and 2.11 macros, but these are only string replacements
    Jisoo Park
    @guersam
    Have anyone used Macwire 2.0 with Play 2.4? I tried to update but it fails with the following errors:
    [error] /home/guersam/workspace/github/macwire/examples/play24/app/com/softwaremill/play24/AppApplicationLoader.scala:36: Found multiple values of type [slick.driver.H2Driver.api.Database]: [List(db, db)]
    [error]   val seed = wire[Seed]
    [error]                  ^
    [error] /home/guersam/workspace/github/macwire/examples/play24/app/com/softwaremill/play24/AppApplicationLoader.scala:31: Cannot find a value of type: [String]
    [error]   lazy val router: Router = wire[Routes] withPrefix "/"
    [error]                                 ^
    [error] two errors found
    [error] (compile:compileIncremental) Compilation failed
    It seems that macwire 2.0
    • recognizes overridden (abstract) member as another value
    • does not take secondary constructors into account (even if it's annotated with @javax.inject.Inject())
    Jisoo Park
    @guersam
    Just opened adamw/macwire#82
    Renato Cavalcanti
    @renatocaval
    Hi guys, do any of you have encountered issues play logging and macwire?
    If I use this example: https://github.com/adamw/macwire#play24x, logging get muted
    I don’t think the problem resides in macwire, but in extending Play’s ApplicationLoader
    My impression is that somehow the logging configuration won't be loaded
    Renato Cavalcanti
    @renatocaval
    Ok, this it the trick
    when using macwire with play, make sure you configure the logging as such:
    class AppApplicationLoader extends ApplicationLoader {
      def load(context: Context) = {
    
        Logger.configure(context.environment)
    
        (new BuiltInComponentsFromContext(context) with AppComponents).application
      }
    }