[PSR-7] Quiz #2

[Crypto Compress]

Hello List,

here is the beloved Quiz to challenge your knowledge about the concepts
in PSR-7:

What is a "ValueObject"?

a) simple object enclosing values: (int)42, (string)"2015-03-18", ...
b) complex object enclosing objects: (UriInterface)$uri,
(StreamableInterface)$stream, ...

As always this quiz is very controversial so please stay polite and
logically consistent. :)

Enjoy!

cryptocompress

[Dracony]

What do you mean by VlaueObject? I don't see it here: https://github.com/php-fig/fig-standards/blob/master/proposed/http-message.md

[Crypto Compress]

Am 18.03.2015 um 13:19 schrieb Dracony:
> What do you mean by VlaueObject? I don't see it
> here: https://github.com/php-fig/fig-standards/blob/master/proposed/http-message.md

You are absolutely right. It's hidden here:
https://github.com/php-fig/fig-standards/blob/master/proposed/http-message-meta.md#why-value-objects

[Dracony]

Wow, that doesn't really sound like a good idea. Getting a clone of the object when getting URI and message sounds like a good idea, but the method name should include Clone somewhere then. It's super easy to forget about 'clone' when implementing the interface

On Wednesday, March 18, 2015 at 11:44:34 AM UTC+1, Crypto Compress wrote:

[Crypto Compress]

It's not at all about naming this time. Some quotes from the meta-document:

> Messages are values where the identity is the aggregate of all parts
> of the message;

ValueObjects do not have identity. Aggregates are complex offtopic
objects. This is only to cause confusion?


> a change to any aspect of the message is essentially a new message.

There are no clarifications why changing "X-Cache" header is essentially
a new message.


> This is the very definition of a value object.

It's intrigue to ask about the very definition of a message?


> The practice by which changes result in a new instance is termed
> immutability,

What is the right term for "not allowing changes"?
Awkward and very dangerous misinformation which already get traction on
conferences and presentations.


> and is a feature designed to ensure the integrity of a given value.

Equally immutability is a feature to ensure integrity of any given
object too.

[Stefano Torresi]

Hello,

I don't see how the fact that the a value object composing other value objects affects its value semantics. If such semantics are complex enough to be represented by a compositions of multiple value objects, then so be it; it's not against the pattern in any way. I couldn't find anywhere any dogma stating that "value objects should not be aggregated".

The rationale about every design decision of the proposal is not "hidden" in any way, it's there in the meta document, as you have found.

The fact that "with*" methods need to return a new instance is outlined by the first line of each docblock, by the words "Create a new instance with... etc.". Personally I find this hard to miss, the docblock is the least you're supposed to read when implementing an interface.

On a personal bottom line, I find the remarks in this thread very little constructive at this stage, if not unnerving.

Best regards.

Stefano Torresi

[Dracony]

I do agree that it doesn't matter what is inside the actual object and whether it has methods. Being a ValueObject has nothing to do with not having and such, it's just about cloning. I see the description in the docblock, but imho someone could miss it. Although if the general consensus is that a docblock is enough I'm ok with that

On Wednesday, March 18, 2015 at 11:44:34 AM UTC+1, Crypto Compress wrote:

[Crypto Compress]

Am 18.03.2015 um 14:20 schrieb Stefano Torresi:
> Hello,
>

Hello Stefano,

> I don't see how the fact that the a value object composing other value
> objects affects its value semantics. If such semantics are complex
> enough to be represented by a compositions of multiple value objects,
> then so be it; it's not against the pattern in any way.

By definition VO is a simple object. If we have something so complex,
may be there is a better pattern?
=> Entity, Aggregate, ...
If all we have is a hammer, everything looks like a nail.

> I couldn't find anywhere any dogma stating that "value objects should
> not be aggregated".

Yes, it's offtopic to state this in VO context. Aggregates should be
aggregated.

> The rationale about every design decision of the proposal is not
> "hidden" in any way, it's there in the meta document, as you have found.
>
> The fact that "with*" methods need to return a new instance is
> outlined by the first line of each docblock, by the words "Create a
> new instance with... etc.". Personally I find this hard to miss, the
> docblock is the least you're supposed to read when implementing an
> interface.

Yes, there are very concrete implementation details required to fulfil a
contract/interface (as docblock comments). Sounds strange?

> On a personal bottom line, I find the remarks in this thread very
> little constructive at this stage, if not unnerving.

I cherish your opinion and tend to disagree. This visualization is vital
to understand the implications of PSR-7 and there will be no other point
in time as ppl get this misinformation in their minds.

Thank you.

[Dracony]

By definition VO is a simple object.

Well that's a very brad term. A better definition is cloning + equality not based on identity.

At any rate the name of the pattern doesn't matter,the point is in  the immutability

On Wednesday, March 18, 2015 at 11:44:34 AM UTC+1, Crypto Compress wrote:

[Crypto Compress]

Am 18.03.2015 um 15:11 schrieb Dracony:

By definition VO is a simple object.

Well that's a very brad term. A better definition is cloning + equality not based on identity.

At any rate the name of the pattern doesn't matter,the point is in  the immutability

A wrong and misplaced pattern will disable and mislead ppl. If wrong-usage spread across many frameworks it will handicap development and understanding for a very long time. Immutability can be achieved with every object. It's a horrible excuse to enforce cloning.

[Roman Tsjupa]

Yes that is why I suggested not mentioning ValueObject at all and just add Copy suffix to method names doing this.

Actually calling it a ValueObject is also kind of wrong from the perspective that its not possible to enforce assign-by-copy off a specific class in PHP. Having a method that copies an object doesnt make it a ValueObject, since other methods may not have that behaviour and pass it by reference

--
You received this message because you are subscribed to a topic in the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/php-fig/CwRYT7NfhQM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/55098A64.6010100%40googlemail.com.
For more options, visit https://groups.google.com/d/optout.

[Matthieu Napoli]

Instead of coming up with a quiz why not stating the problem clearly and directly next time? That would save some time to everyone.

What improvements do you suggest to the wording of the meta-document?

[Crypto Compress]

Am 20.03.2015 um 00:31 schrieb Matthieu Napoli:
> Instead of coming up with a quiz why not stating the problem clearly
> and directly next time? That would save some time to everyone.

Sorry! Everyone want it to happen, including me.

>
> What improvements do you suggest to the wording of the meta-document?

No way to improvement this one. People need to gather know-how/knowledge
from the blue bible.
http://www.amazon.de/dp/0321125215

[Matthieu Napoli]

Domain Driven Design is not meant to be applied to every software problem. It's explained clearly in the book, and it's even the first sentence on Wikipedia:

> DDD is an approach to software development for complex needs

I don't expect a PSR to be pushing DDD on all the PHP applications and libraries out there :)

The vocabulary of the meta document shouldn't be considered to be DDD vocabulary, and VO and related words shouldn't be considered equal to DDD VO, entity, etc... (and yes those words exist outside of the DDD world)

[Crypto Compress]

Am 20.03.2015 um 23:53 schrieb Matthieu Napoli:

Domain Driven Design is not meant to be applied to every software problem. It's explained clearly in the book, and it's even the first sentence on Wikipedia:

> DDD is an approach to software development for complex needs

I don't expect a PSR to be pushing DDD on all the PHP applications and libraries out there :)

The vocabulary of the meta document shouldn't be considered to be DDD vocabulary, and VO and related words shouldn't be considered equal to DDD VO, entity, etc... (and yes those words exist outside of the DDD world)

Shure! So we need way more implementations and fails as from me alone. I can't lift this one. Sorry again!

[Alessandro Pellizzari]

On 2015-03-18 13:20, Stefano Torresi wrote:

> I dont see how the fact that the a value object composing other value

> objects affects its value semantics. If such semantics are complex
> enough to be represented by a compositions of multiple value objects,

> then so be it; its not against the pattern in any way. I couldnt find

> anywhere any dogma stating that "value objects should not be
> aggregated".

It is (against the definition):

"a value object is a small object that represents a simple entity"

by definition, a composed object is not a simple entity.

> On a personal bottom line, I find the remarks in this thread very
> little constructive at this stage, if not unnerving.

I missed the point in the discussion where it was decided they were
value objects. Maybe it happened in a different mailing list, or on
GitHub, I don't know. I don't even know how to search the mailing list
to find it. If anybody knows where it was decided, please post a link)

But I wrote more than one month ago, in my last message on this
subject, that they are NOT value objects.

I got no response.

What I find a little unnerving is that Zend Framework is already
advertising their v3 as based on PSR-7, when the vote has not even
started, and many people expressed concerns about how it is going to be.

I also feel this mailing list is quite useless, if discussion about
PSRs is held on different media (github, other mailing lists, IRC,
whatever).

Bye.

[Matthew Weier O'Phinney]

On Wed, Mar 18, 2015 at 10:15 AM, Alessandro Pellizzari <al...@amiran.it> wrote:
> On 2015-03-18 13:20, Stefano Torresi wrote:

<snip>

>> I dont see how the fact that the a value object composing other value
>> objects affects its value semantics. If such semantics are complex
>> enough to be represented by a compositions of multiple value objects,
>> then so be it; its not against the pattern in any way. I couldnt find
>> anywhere any dogma stating that "value objects should not be
>> aggregated".
>
> It is (against the definition):
>
> "a value object is a small object that represents a simple entity"

and you omit the rest of the defintion:

"….whose equality is not based on identity"

(assuming you're using the wikipedia definition, as your original
quote is verbatim from that article)

> by definition, a composed object is not a simple entity.

There is no stipulation in any definition I've read that a value
object cannot compose other objects. In fact, I've seen quite the
opposite in practice, even in examples of value objects, as I've often
seen DateTime objects, Currency objects, and more composed as part of
another value object. I'm curious what definition you're working with
when you make the above assertion.

Essentially, a value _can_ be an aggregate of other values, including
value objects. I think the only debatable part of the definition is
what is meant by "simple," and the various value object examples I've
seen vary widely in scope.

<snip>

> I missed the point in the discussion where it was decided they were value
> objects. Maybe it happened in a different mailing list, or on GitHub, I
> don't know. I don't even know how to search the mailing list to find it. If
> anybody knows where it was decided, please post a link)

The verbiage has been in the spec and the meta document since before I
took over as editor; a `git blame` will likely tell you when/where it
was added. In terms of the current incarnation, where we've taken this
to also include immutability, search for that word in the mailing
list, as most discussions were around that aspect of value objects.

> But I wrote more than one month ago, in my last message on this subject,
> that they are NOT value objects.
>
> I got no response.

I didn't respond, as I don't agree, and, frankly, am very much done
with debating semantics at this point. The question at this point
should be: does the design model the messages in a solid manner that
addresses the criteria outlined in the spec and the meta document?
Debating on whether or not they are _actually_ value objects is
something we could go on and on about, and doesn't answer that
question at all.

> What I find a little unnerving is that Zend Framework is already advertising
> their v3 as based on PSR-7, when the vote has not even started, and many
> people expressed concerns about how it is going to be.

ZF3 will be using PSR-7, in whatever form it ends up taking at the
time of acceptance. If it doesn't pass the vote at this time, I'll
work with those who voted against it to determine what would make the
proposal work for them, we'll push a new draft, and we'll vote again.
ZF3 is _not_ moving forward with PSR-7 plans until after an acceptance
vote passes. However, it makes little sense for us to bump major
versions without supporting PSR-7, as that will limit adoption. I want
to see PSR-7 adopted rapidly, whatever form it takes, as I think it's
quite important for interoperability and for PHP users in general.

> I also feel this mailing list is quite useless, if discussion about PSRs is
> held on different media (github, other mailing lists, IRC, whatever).

All decision making happens on this list. Any discussion I have had
about PSR-7, whether in person, on IRC, on twitter, or over GitHub, I
have brought back to the list, where I have summarized and outlined
decisions or approaches I planned to make. From what I've seen, other
PSR editors do the same. I have also referenced PSR-7 in all thread
subjects to make searching for PSR-7 topics easier. Honestly, I don't
know what more I or other editors could do at this point to make
things easier; sometimes building consensus is messy.

--
Matthew Weier O'Phinney
mweiero...@gmail.com
https://mwop.net/

[Stefano Torresi]

Hello Alessandro,

2015-03-18 16:15 GMT+01:00 Alessandro Pellizzari <al...@amiran.it>:

It is (against the definition):

"a value object is a small object that represents a simple entity"

by definition, a composed object is not a simple entity.

Look, one could ravel in definitions for pretty much anything, quite frankly I don't care. I am more interested in the concepts involved here, and even if value objects are usually "small" and "simple", the key point is value semantics: the fact that they have no identity and their equality is is based on their values. This is explained in pretty much any academic source; sticking so strictly to the literal definition is, in my opinion, a very narrow perspective, if not just nitpicking.

"Simple" and "small" are generic words, you can go as far as you want with them, I genuinely don't see the point.
What I think the definition really says is with "simple" is that it shouldn't have any behaviour, it's only a value. "small" doesn't mean anything, really. Is there an arbitrary number of properties that defines when a value object stops being a value object because it's not "small" enough?

My point is that composition doesn't affect the semantics at all: I can implement DateTime as a value object even if I designed it as a composition of Date, Time and Timezone value objects, as well as I can implement Date as value object even if I composed it with Day, Month, and Year value objects. Et cetera, et cetera.

Besides, "composite" doesn't necessarily mean "complex".

 

I missed the point in the discussion where it was decided they were value objects. Maybe it happened in a different mailing list, or on GitHub, I don't know. I don't even know how to search the mailing list to find it. If anybody knows where it was decided, please post a link)

It was stated in the very first thread when MWOP stepped in as editor:

https://groups.google.com/d/msg/php-fig/CTPRa2XP8po/QHBS-AKwfrYJ

 

But I wrote more than one month ago, in my last message on this subject, that they are NOT value objects.

I got no response.

Well, I don't know, maybe your points weren't compelling enough... :-p

 

I also feel this mailing list is quite useless, if discussion about PSRs is held on different media (github, other mailing lists, IRC, whatever).

This mailing list is actually where most of the stuff happens.
There are no different mailing lists for this PSR (being the security PSR the only one with a separate ML), and discussions started on github are usually redirected here. 
ML and IRC are not mutually exclusive, the latter is used when tighter discussion pace is desired.
When some discussion happens outside these channels, editors usually post a report on the list to keep everyone in the loop.

Regards.

 

Stefano Torresi 

[Crypto Compress]

> There is no stipulation in any definition I've read that a value
> object cannot compose other objects. In fact, I've seen quite the
> opposite in practice, even in examples of value objects, as I've often
> seen DateTime objects, Currency objects, and more composed as part of
> another value object. I'm curious what definition you're working with
> when you make the above assertion.
>
> Essentially, a value _can_ be an aggregate of other values, including
> value objects.

"Value object of value objects" is a recursive definition and flatten
recursion is havy work but good design.
Every message object does have an identity! Even in current implemetation.
There are better names for what you have designed here. I really don't
know why you try to fit all objects in same type.

> I didn't respond, as I don't agree, and, frankly, am very much done
> with debating semantics at this point.

This is your killer argument since the beginning. Who need debates... We
need user value! *facepalm*

> The question at this point should be: does the design model the messages in a solid manner that
> addresses the criteria outlined in the spec and the meta document?

The tail wagging the dog. *more facepalm*

> Debating on whether or not they are _actually_ value objects is
> something we could go on and on about, and doesn't answer that
> question at all.

Yes, we should debate alternatives. Learning is hard for old ppl.

>> I also feel this mailing list is quite useless, if discussion about PSRs is
>> held on different media (github, other mailing lists, IRC, whatever).

Only -1 and 0 voters have founded their vote on this mailinglist.

[Matthew Weier O'Phinney]

On Tue, Mar 24, 2015 at 11:20 AM, Crypto Compress
<cryptoc...@googlemail.com> wrote:
>
>> There is no stipulation in any definition I've read that a value
>> object cannot compose other objects. In fact, I've seen quite the
>> opposite in practice, even in examples of value objects, as I've often
>> seen DateTime objects, Currency objects, and more composed as part of
>> another value object. I'm curious what definition you're working with
>> when you make the above assertion.
>>
>> Essentially, a value _can_ be an aggregate of other values, including
>> value objects.
>
>
> "Value object of value objects" is a recursive definition and flatten
> recursion is havy work but good design.

We have exactly ONE case where we have a composed object, the URI. We
avoided it for quite some time, but the benefits of representing this
value as an object outweighed those of not doing so. We've kept the
overall structure flat, including ensuring that headers are direct
members of the messages.

> Every message object does have an identity!

Yes: the message itself is the identity. The identity is not formed by
a single field (such as the URI), but by the aggregate (request
method, headers, body for a request; status code, headers, and body
for a response).

> Even in current implemetation.
> There are better names for what you have designed here. I really don't know
> why you try to fit all objects in same type.
>
>> I didn't respond, as I don't agree, and, frankly, am very much done
>> with debating semantics at this point.
>
> This is your killer argument since the beginning. Who need debates... We
> need user value! *facepalm*

We have debated PLENTY. I'm asking to debate ON THIS SPECIFICALLY:

>> The question at this point should be: does the design model the messages
>> in a solid manner that
>> addresses the criteria outlined in the spec and the meta document?
>
> The tail wagging the dog. *more facepalm*

No, it's not. Design and requirements have been discussed in minute
detail. The point of bringing this to a vote is to decide if the
specification and design meet those requirements.

>> Debating on whether or not they are _actually_ value objects is
>> something we could go on and on about, and doesn't answer that
>> question at all.
>
>
> Yes, we should debate alternatives. Learning is hard for old ppl.

Yes, please, let's continue with the ad hominem attacks.

*sigh*

We have debated many, many alternatives, and I've implemented quite a
few myself.

If you are not convinced: talk to your voting representative and
convince them to vote against PSR-7.

>>> I also feel this mailing list is quite useless, if discussion about PSRs
>>> is
>>> held on different media (github, other mailing lists, IRC, whatever).
>
>
> Only -1 and 0 voters have founded their vote on this mailinglist.

Thank you for insulting all those who have voted +1 and who have done
their homework. I'm sure they appreciate it.

[Crypto Compress]

>>> There is no stipulation in any definition I've read that a value
>>> object cannot compose other objects. In fact, I've seen quite the
>>> opposite in practice, even in examples of value objects, as I've often
>>> seen DateTime objects, Currency objects, and more composed as part of
>>> another value object. I'm curious what definition you're working with
>>> when you make the above assertion.
>>>
>>> Essentially, a value _can_ be an aggregate of other values, including
>>> value objects.
>>
>> "Value object of value objects" is a recursive definition and flatten
>> recursion is havy work but good design.
> We have exactly ONE case where we have a composed object, the URI. We
> avoided it for quite some time, but the benefits of representing this
> value as an object outweighed those of not doing so. We've kept the
> overall structure flat, including ensuring that headers are direct
> members of the messages.

With URI and Stream there are *two* havy objects in a message. The
recursive definition as "VO of VOs" is flawed, no matter how often you
have seen this. It's redundant to discuss headers or anything else. This
wrong definition will not go away by redefining or ignoring it and will
confuse ppl. (As you have not renamed withBody() method to withStream()
nor discussed this change on this list, it's easy to overlook the
StreamableInterface.)

>> Every message object does have an identity!
> Yes: the message itself is the identity. The identity is not formed by
> a single field (such as the URI), but by the aggregate (request
> method, headers, body for a request; status code, headers, and body
> for a response).

No: "X-Cache" Header has nothing to do with the Identity of the Message.
I would argue that all meta-infos are non-identifying. Your wife even
changed as important information as her name but not her identity. I'm
glad you thought about the identity of objects but again this topic was
not discussed on this list and is half-done.

>>>> I also feel this mailing list is quite useless, if discussion about PSRs
>>>> is held on different media (github, other mailing lists, IRC, whatever).
>>
>> Only -1 and 0 voters have founded their vote on this mailinglist.
> Thank you for insulting all those who have voted +1 and who have done
> their homework. I'm sure they appreciate it.

There are no messages from +1 voters on "why" topic on this list. A
simple observation.

In fact you never, not once, not on list nor github nor private
discussed any topics i brought up without flames. Not even topics you
implemented in this PSR.