by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
Tim Cooper
@coop
@fran-worley I believe Bundler does that.
Fran Worley
@fran-worley
I mean the dry-rb.org site
Tim Cooper
@coop
I know - I’m saying that bundler does something similar.
Fran Worley
@fran-worley
Ah didn't know that.
It might solve a lot of the syntax changing queries if people could view the docs on the site by version vs Master. e.g. http://dry-rb.org/gems/dry-validation/v-0.7.4
Tim Cooper
@coop
I like it.
Bundler just copy over the docs for each release - https://github.com/bundler/bundler-site/tree/master/source
Fran Worley
@fran-worley
Yeah, I'm talking about taking what is on the dry-rb site rather than the readme/docs for the repo itself
that way when versions get bumped and the docs/ examples on the site are changed those running old versions don't miss out
Tim Cooper
@coop
I totally get what you mean, I’m just linking to how bundler is doing it. Their docs site is generated from https://github.com/bundler/bundler-site. The dry-rb.org docs site is generated from https://github.com/dry-rb/dry-rb.org/.
Fran Worley
@fran-worley
Sorry, my brain is not engaging... I know understand what you mean!
I thought you meant that bundler does some magic with rubygem docs for versions... must get a :coffee: before I do anything else!
Tim Cooper
@coop
:P
Tim Cooper
@coop

@timriley I’ve been reading over your article again and I have a feeling that you meant to say that an Article is an entity not a value object. From your article you quote the definition of a value object as:

A value object is one whose notion of equality is based on the values of the attributes it contains, not its object identity.

I agree with this but your article class includes an id field:

class Article < Dry::Types::Struct
  attribute :id, Types::Strict::Int
  attribute :title, Types::Strict::String
  attribute :body, Types::Strict::String
end

I think we both will agree that Article.new(id: 1, title: “title”, body: “body”) != Article.new(id: 1, title: “amended title”, body: “body”) in code land but in the real world the objects are the same, they’re both referring to the exact same article (the second article is modified and therefore its title is different).

IMO a value object is something that is only identifiable by its attributes, things like money, name, address and credit cards.

I did enjoy the article though, just my 2 cents.

Simon Schmid
@sled
@coop :+1:
Tim Riley
@timriley
Good point, @coop. id being there is kind of a smell that it’s not a true value object.
Simon Schmid
@sled
but it leaves me wondering how to handle objects which could be in an invalid state :)
Tim Riley
@timriley
Even though the the equality methods on Dry::Types::Struct still take into account all the attributes.
@sled we just treat invalid data as just that - a hash of invalid params/attributes
pass it around until like that the user can make it valid
Simon Schmid
@sled
@timriley what do you think about an anonymous class which represents the hash as simple struct with attr_readers ?
kind of a "representer" of the invalid data
Tim Riley
@timriley
What does that get you over a hash?
Simon Schmid
@sled
@timriley compatibility with existing libraries which can't handle hashes directly
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 :)