by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 09:18
    k0va1 opened #71
  • 08:37
  • May 29 21:51
    armstnp closed #125
  • May 29 21:51
    armstnp commented #125
  • May 29 20:27
    sankalpk starred dry-rb/dry-types
  • May 29 14:43
    josh-dev-test starred dry-rb/dry-types
  • May 28 16:39
    kietnguyen starred dry-rb/dry-types
  • May 27 09:03
    Travis dry-rb/dry-transaction (release-0.13) errored (353)
  • May 26 18:01
    marzdrel starred dry-rb/dry-system
  • May 25 09:50
    k0va1 starred dry-rb/dry-monads
  • May 22 10:57
    solnic commented #146
  • May 21 22:24
    armstnp edited #125
  • May 21 22:23
    armstnp edited #125
  • May 21 22:17
    armstnp labeled #125
  • May 21 22:17
    armstnp opened #125
  • May 21 10:54
    jezstephens commented #146
  • May 21 09:25
    solnic labeled #146
  • May 21 09:23
    solnic commented #146
  • May 20 17:41
    jezstephens labeled #146
  • May 20 17:41
    jezstephens opened #146
Tim Riley
@timriley
heh. Well I guess that’d be helpful then :)
Simon Schmid
@sled
mh or maybe a simple decorator which just delegates to the fetch method
Tim Cooper
@coop
http://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215 - if you haven’t read this I would strongly recommend reading through it. A lot of the dry / rom stuff talks about building domain orientated systems, this book was the original instigator (I believe).
Tim Riley
@timriley
Cool, thanks for the recommendation @coop
Simon Schmid
@sled
thanks! :)
Tim Cooper
@coop
I actually have a copy you could borrow next time you’re in Brisbane :P
Tim Riley
@timriley
hehe
Tim Riley
@timriley
@nepalez Congrats on the first dry-initializer release :) Would you like to pen a little blog post for the dry-rb site announcing it?
Tim Riley
@timriley
@coop thinking I could maybe add a little parenthetical aside explaining the difference between entities and value objects – do you reckon that’d help?
Tim Cooper
@coop
I think it would help.
Tim Riley
@timriley

@coop How’s this read?

(Technically, these examples are entities rather than strict value types, because we include the record IDs in their attributes, which you'd expect to be the key indicator of equality. However, in practice, Dry::Types::Struct instances still check for equality across all attributes, and in our apps we only ever instantiate these objects from known-good database data, which means they still behave effectively as value objects. So let's continue!)

Tim Cooper
@coop
That clears it up.
Tim Riley
@timriley
Cool, and thanks for the discussion!
Tim Cooper
@coop
@timriley do you ever mutate these and write them back to the database? And when I say “mutate” I’m talking about returning a new value object with the changed attributes.
Tim Riley
@timriley
Nope, we just work with hashes when we’re persisting changes. Get a params hash from a form, adjust as necessary in an “operation” object, run it through validation schema, pass it to a ROM command.
Tim Cooper
@coop
From your example I could imagine something: changed_article = article.with_title(“my new title”) and then pass changed_article to the DB.
Ah ok.
Tim Riley
@timriley
Yeah. I think a lot of this will be clearer once I can start to piece a few things together.
But I’m trying to avoid 6,000 word articles ;)
Tim Cooper
@coop
:P
The idea of hashes is fine, we do something similar for event sourcing, each aggregate keeps list of events to persist to the database which are effectively an array of hashes.
We wrote so much code that is similar to dry-types.
Tim Riley
@timriley
heh
Tim Cooper
@coop
All of our events are typed… We enforce types when constructing events. I’ve tried substituting for dry-t and dry-v but it’s quite a lot of work. It will be worth it because dry-t and dry-v integrate so nicely, we’ll be able to delete a lot of code at the end.
Tim Riley
@timriley
Cool, that’ll be nice to get in place :)
Andy Holland
@AMHOL
hanami/validations#98
Fran Worley
@fran-worley
@AMHOL Some sound arguments, it's just a shame that there can't be some kind of consensus amongst rails alternative ruby 'frameworks'.
Andy Holland
@AMHOL
@fran-worley Yeah, the point about not being able to wrap the API was the only real valid argument IMO, but each to their own I guess
Fran Worley
@fran-worley
@AMHOL I can kind of see the argument for having lots of dependencies but if it keeps code DRYer then why wouldn't you...
Andy Holland
@AMHOL
Yeah, I think the adding more gems argument is a non-issue
Fran Worley
@fran-worley
I'd rather have 30 small dependencies that use each other than 5 large ones that have to re-implement common functionality. I just appreciate that others don't agree.
Andy Holland
@AMHOL
Unless those gems make changes to the runtime environment
:+1: * :100:
Fran Worley
@fran-worley
Yeah. Also the point about the wrapable API, isn't this being addressed to some degree by the discussions on custom input processors and Error handlers
and surely there is nothing to stop you writing your own macros to reintroduce the validates :title, :presence type syntax ?
Simon Schmid
@sled
I'm currently working on something like dry-activemodels, basically composes the errors and output of a schema to an activemodel
(error messages, output hash) => activemodel and (full type) => activemodel
some simple delegations
but getting attribute translations and form builder compatibility :)
Andy Holland
@AMHOL
Well you could build an entirely custom API and make use of the AST in theory, but I think Luca would rather spend the time implementing a similar validation library from scratch, rather than go to that effort and have the underlying dependencies too
Be interesting to see what Piotr thinks when he gets back though, I'm not all that familiar with dry-validation myself
Simon Schmid
@sled
I think the only external gem dependency of dry-* is the Kleisli gem
Andy Holland
@AMHOL
Also concurrent-ruby
Simon Schmid
@sled
yep concurrent-ruby is a beast ;)
Andy Holland
@AMHOL
It is indeed, I preferred thread-safe TBH
But again, people don't want too many dependencies, so lets have a gem for utitility classes, a gem for managing concurrency and a gem for active anything
I can't wait to see what Tim does with https://github.com/icelab/dry-web-skeleton tho, hopefully will be able to get the full stack running on top of dry and rom soon
Fran Worley
@fran-worley
It would be good to hear Piotr's opinion but I remember him saying a while ago that his vision for Macros was to enable people to build their own. I know that there was talk a while ago of building something into Reform to make the migration to Dry-V easier.
Andy Holland
@AMHOL
Oh cool, I guess I missed that
Fran Worley
@fran-worley
I could be wrong and I know that at this stage it's not been explored to its full potential but that combined with custom processors for inputs and errors would in theory allow you to 'wrap' the library.