These are chat archives for dry-rb/chat

11th
Jan 2016
Kareem Hepburn
@magicalbanana
Jan 11 2016 15:46
What’s gt? for?
Luca Guidi
@jodosha
Jan 11 2016 15:47
@magicalbanana Greater than
Kareem Hepburn
@magicalbanana
Jan 11 2016 15:47
Ah, lol.
If I stuck with C# I would prolly guessed that. Ruby and it’s conventions has made my abbreviation skills weak.
Piotr Solnica
@solnic
Jan 11 2016 15:50
hah :)
Kareem Hepburn
@magicalbanana
Jan 11 2016 15:51
@solnic where I work that gt? would never fly. They emphasize on convention here (the rails one) too much. :(
@solnic so is dry-validations stable?
Piotr Solnica
@solnic
Jan 11 2016 15:52
no, it’s 0.4.2 atm
will push 0.5.0 later today or tomorrow
Kareem Hepburn
@magicalbanana
Jan 11 2016 15:52
Ah, how long before you think it becomes stable?
Piotr Solnica
@solnic
Jan 11 2016 15:52
I’ll release 1.0.0 once I’m done with error message compilation optimizations
it’s my personal pet peeve :joy:
targeting February for 1.0
Kareem Hepburn
@magicalbanana
Jan 11 2016 15:53
I get that. I think I’ll start doing benchmarks for all the validators I am aware of. Should be good.
Piotr Solnica
@solnic
Jan 11 2016 20:21
dry-data 0.5 and dry-validation 0.5 were released and now they both depend on the new dry-logic gem
@kwando I added "default value” support in this release, I remember you asked about a DSL for that the other day…it’s a bit different than in virtus and currently only supports a simple value, so no procs or method names are supported
Tim Riley
@timriley
Jan 11 2016 20:40
An interesting thing I’m seeing with the rodakase apps we have and these container-based gems with finalization (i.e. rom and dry-data now, with its types module) is that if you want 2 distinct places for registering entities with those gems (i.e. in our rodakase app we have “main” and “admin” sub-apps) then it becomes pretty hard to do.
since the finalization needs to somehow span the boot sequence of both of the sub-apps. Or perhaps they ideally have their own containers/namespaces, which isn’t quite possible with those gems, I think.
Piotr Solnica
@solnic
Jan 11 2016 20:43
"Entities" being?
Tim Riley
@timriley
Jan 11 2016 20:44
ah, so whatever the gem’s concerned with registering: relations, commands, mappers, etc. for rom and then type definitions for dry-d
Tim Riley
@timriley
Jan 11 2016 20:56
I think in dry-d’s case it’s not too bad. I’d just configure a top-level Types namespace globally in the app, then use modules underneath that if any of the sub-apps need specific types defined.
The finalizing bit might be tricky still. Let me look at the code.
Andy Holland
@AMHOL
Jan 11 2016 21:00
@solnic we spoke about maybe doing something like this rather than the finalize/namespace configuration, don't know if you remember?
module Dry
  module Data
    def self.register_types(mod)
      define_constants(mod, container._container.keys)
    end
  end
end
Tim Riley
@timriley
Jan 11 2016 21:00
Making it an explicit thing you can do a number of times?
Andy Holland
@AMHOL
Jan 11 2016 21:00
Then you can do:
module Core
  module Types
    Dry::Data.register_types(self)
  end
end
@timriley yeah
Tim Riley
@timriley
Jan 11 2016 21:04
I like that approach.
Andy Holland
@AMHOL
Jan 11 2016 21:05
Me too :)
Piotr Solnica
@solnic
Jan 11 2016 21:21
there’s no need for that, types are objects, assign them to constants and you’re done
the finalization is there so that dry built-in types are defined within your namespace
Tim Riley
@timriley
Jan 11 2016 21:22
Ah, right.
Piotr Solnica
@solnic
Jan 11 2016 21:22
we can provide default namespace that you can just include it
include Dry::Data::Types::BuiltIn or something
Piotr Solnica
@solnic
Jan 11 2016 21:29
@timriley re configuring deps, you're talking about deps that are places in diff subapps but share common booting code?
Tim Riley
@timriley
Jan 11 2016 21:30
In this case they share common boot code (relations), yeah. My situation was that I thought I’d need a mapper in a sub-app to map to one of its own entity classes – turns out I don’t, so I’ve avoidede the issue for now.
Piotr Solnica
@solnic
Jan 11 2016 21:32
I am working on improving this. Ie it is possible to define rom as a standalone component shared between subapps. So it is not part of the booting process of any app
Tim Riley
@timriley
Jan 11 2016 21:33
ah, interesting
Piotr Solnica
@solnic
Jan 11 2016 21:33
So anything that requires rom and some of its components, can define it as a dep and it will trigger its booting etc
Tim Riley
@timriley
Jan 11 2016 21:34
How would the finalization of rom’s own container work there?
Piotr Solnica
@solnic
Jan 11 2016 21:35
When you require it through dry-component it will trigger its booting so it will create its container etc
Tim Riley
@timriley
Jan 11 2016 21:39
the dry-component container, or rom’s own internal container?
The issue I was foreseeing (which I haven’t hit in real life, yet) is when rom comes in a shared component for the shared things, but subapps also add their own specific things (i.e. mappers, maybe even relations or extra commands etc.) is that you’d need to somehow delay finalizing rom until everything had booted
Piotr Solnica
@solnic
Jan 11 2016 21:47
I will try a setup like that and make it work
It boils down to sharing the same gateway instances across entire app between its subapps