Dmytro Naumenko

Discussion has started in #1927

Never thought about it this way, and it depends, as I see https://stackoverflow.com/a/32365658 If you prefer calling them vise-versa in this project – let me know, I'm OK with that.

Yes, indeed, it's a bit more straightforward. Moved mappings to Bill. Got something like this: ```php final class BillMapper extends Mapper { public function hydrate($entity, array $data) { $data['sum'] =...

I also don't see much sense in creating inconsistent VO in `init()` to hydrate them sometime later. Do you think that creating a fully-built VO in custom `Mapper::init()` is OK?

> What about extract / hydrate methods? You mean extract / hydrate methods for VO that was fully created in `init()`? ``` public function hydrate($entity, array $data) { return $entity;...

The `attach()` call [here](https://github.com/cycle/orm/blob/0aac4295dca682a326d8d18a7013a7040a92d06e/src/ORM.php#L171) (to be precise, an `offsetSet()` call inside of `attach()`) requires `$e` to be an object, so I should create some placeholder object in the `init()` method...

That's also true, but both Unit and Currency entities are immutable objects in my domain. They also exist in the DBMS and have a PK, so they can be created...

Yes, sure) So you think it's OK to create dumb `stdClass()` in the `init()` method of VO mappers?

We need a dumb object and `stdClass` seems to bee dumb enough) What about writing docs? See end of https://github.com/cycle/orm/issues/88#issuecomment-614723084

This seems to be a bit harder than I expected :) After I managed to hydrate sum through the account relation... ```php public function hydrate($entity, array $data) { $data['sum'] =...