[PSR-7] Quiz #1

[Crypto Compress]

Hi List,

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

class Request implements RequestInterface {
...
public function withMethod1($method) {
$new = clone $this;
$new->method = $method;
return $new;
}

public function withMethod2($method) {
$new = clone $this;
$new->setMethod($method);
return $new;
}
...
}

Which of the methods does mutate state?
a) first
b) second
c) both
d) none

It is very hard to get things right on the first attempt, even knowing
the theory. :)

Enjoy!

cryptocompress

[Matteo Beccati]

Hi,

On 02/02/2015 13:02, Crypto Compress wrote:
> public function withMethod2($method) {
> $new = clone $this;
> $new->setMethod($method);

Well, if you have withMethod, there shouldn't be setMethod in the first
place.


Cheers
--
Matteo Beccati

Development & Consulting - http://www.beccati.com/

[Alessandro Pellizzari]

On 2015-02-02 12:02, Crypto Compress wrote:
> here is a small Quiz to challenge your knowledge about the concepts
> in PSR-7:

> $new->method = $method;
> $new->setMethod($method);

> Which of the methods does mutate state?

If immutability is implemented correctly, neither of these will work,
exiting with an error message.

The correct implementation will be like

public function withSomething($something) {
$state = $this->getAllStateAsArray();
$state['something'] = $something;
$new = new self($state);
return $new;
}

Bye.

[Matthew Weier O'Phinney]

On Mon, Feb 2, 2015 at 6:24 AM, Alessandro Pellizzari <al...@amiran.it> wrote:
> On 2015-02-02 12:02, Crypto Compress wrote:
>>
>> here is a small Quiz to challenge your knowledge about the concepts in
>> PSR-7:
>
>
>> $new->method = $method;
>> $new->setMethod($method);
>
>
>> Which of the methods does mutate state?
>
>
> If immutability is implemented correctly, neither of these will work,

Except that PHP does not support immutability at the language level,
which means we MUST emulate it.

This entire thread is pointless: it's discussing concrete
implementation details, which are out of scope of the interfaces
themselves, and, furthermore, would be better served on php-internals,
as the only place this will ever be truly solved will be in the
language itself.

Please, if you must have these discussions, do it elsewhere, and stop
wasting the time of those of trying to advance the proposal.

> exiting with an error message.
>
> The correct implementation will be like
>
> public function withSomething($something) {
> $state = $this->getAllStateAsArray();
> $state['something'] = $something;
> $new = new self($state);
> return $new;
> }

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

[Matthew Weier O'Phinney]

@cryptocompress:

You have yet to approve of any suggestion by anybody with regards to
this proposal or any others I've seen you comment on. While some of
your comments do have merit, the vast majority are purely acts of
academic oneupmanship (such as this one, which describes a limitation
of the language, and nothing to do with the proposal itself), and do
nothing to further the design goals or merits of the proposals, but
instead waste the time of everybody involved.

I respectfully ask that you direct your efforts somewhere else other
than this group.

> --
> You received this message because you are subscribed to the Google Groups
> "PHP Framework Interoperability Group" group.
> To unsubscribe from this group and stop receiving emails from it, 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/54CF6748.7010606%40googlemail.com.
> For more options, visit https://groups.google.com/d/optout.

[Crypto Compress]

@mwop

> @cryptocompress:
>
> You have yet to approve of any suggestion by anybody with regards to
> this proposal or any others I've seen you comment on.

What do i need to approve? And why?

> While some of your comments do have merit,

Shure, i have done this for years.

> the vast majority are purely acts of academic oneupmanship

Too bad you sweep away all my practical arguments with this
null-argument, instead adopt things you have never done before.

> (such as this one, which describes a limitation of the language, and nothing to do with the proposal itself)

No! My points have nothing to do with PHP! This is about PSR-7
misinterpretations and misconceptions.
You not even try to see how you confuse and harm the whole community
with this crude and hobbling thing you proposing.
There are two argument i have seen by you:
1. i have tried it for the first time and it was cool
2. RTFM

I do understand that it's hard to get things right on first attempt. It
does not help to be so incredible arrogant, however.
That you never done this before is not an excuse to wipe away arguments.

> , and do nothing to further the design goals or merits of the proposals, but
> instead waste the time of everybody involved.

How so? By naming the pitfalls explicitly?

> I respectfully ask that you direct your efforts somewhere else other
> than this group.

I respectfully ask you to stop bullying around and think about the
replies in this thread. They are very well thought-out and exactly on
point. The people know what they are writing about! You need to get this
things right or you will not only shoot yourself in the foot but the
whole community.

[Alessandro Pellizzari]

On 2015-02-02 14:34, Matthew Weier O'Phinney wrote:

> On Mon, Feb 2, 2015 at 6:24 AM, Alessandro Pellizzari
> <al...@amiran.it> wrote:

>> If immutability is implemented correctly, neither of these will
>> work,
>
> Except that PHP does not support immutability at the language level,
> which means we MUST emulate it.

Is there a better way to implement it (correctly) than the one I wrote?

If you implement public attributes or setAttribute() to be able to
clone it and mutate afterwards, you are basically declaring immutability
"just for the sake of it", but not using it correctly.

If the language does not allow to implement it efficiently, why define
an interface that requires it?

> This entire thread is pointless: it's discussing concrete
> implementation details, which are out of scope of the interfaces
> themselves, and, furthermore, would be better served on
> php-internals,
> as the only place this will ever be truly solved will be in the
> language itself.
>
> Please, if you must have these discussions, do it elsewhere, and stop
> wasting the time of those of trying to advance the proposal.

I don't think we are wasting time.
This is exactly (one of) the reason(s) why I opposed immutability: it's
a performance killer if implemented correctly in PHP.
If it's not implemented correctly, what's the reason of forcing it in a
PSR? Just to "be cool"?

If you want to ignore criticism and just go ahead, fine, you are the
coordinator.
All I can do is try to discuss and show my point of view, as I have no
vote, and that's what I am doing.

Bye.

[Matthew Weier O'Phinney]

On Mon, Feb 2, 2015 at 9:53 AM, Crypto Compress
<cryptoc...@googlemail.com> wrote:
> @mwop
>
>> @cryptocompress:
>>
>> You have yet to approve of any suggestion by anybody with regards to
>> this proposal or any others I've seen you comment on.
>
>
> What do i need to approve? And why?

My point is that nothing, ever, is good enough to meet your standards,
whatever they are. And you pick and pick and pick at every proposal,
with very little constructive feedback other than, "this is no good,"
even when the editors make changes based on your feedback.

>> While some of your comments do have merit,
>
> Shure, i have done this for years.

And so have I. And so has everybody on the list. I'm asking for you to
engage in the spirit of consensus, and not to just pick everything
apart.

>> the vast majority are purely acts of academic oneupmanship
>
> Too bad you sweep away all my practical arguments with this null-argument,
> instead adopt things you have never done before.

I apologize for the above ad hominem attack, and retract it. I'm very
frustrated, but that does not excuse the attack.

>> (such as this one, which describes a limitation of the language, and
>> nothing to do with the proposal itself)
>
> No! My points have nothing to do with PHP! This is about PSR-7
> misinterpretations and misconceptions.

Which misinterpretations and misconceptions?

Here's what I've seen from you:

- When we implemented URI interfaces, we specifically indicated they
would only model web-based URIs: i.e., HTTP or HTTPS. But then you
asked why it doesn't allow for mailto: schemes.
- When we implemented a URI interface, and explicitly stated it was to
model only web-based URIs (just as we did with streams), to allow us
to model URIs for the purposes of HTTP messages, you then argued for a
new general-purpose PSR for URIs.
- When asked about immutability or selected mutability, you replied
off-topic by asking what the interfaces *do* (when they have been
described all along as value objects, and not objects with behavior).
- Again, when asking about immutability, you then changed the topic to
ask about the lifetime of the message objects, with no context about
why this was relevant to the discussion. You brought it up again once
selective mutability was implemented, and stated that "this is
crucial." When I and others indicated the way current frameworks work
and what we're targeting (requests are referenced throughout the
application request cycle, as are responses), you argued they
shouldn't be, but would not provide counter-examples to show the
application workflow you envision.
- When asked what the pros/cons of immutability would be, you argued
mutable is a superset of immutable, and argued to remove
incoming/outgoing interfaces. And then later, when immutable instances
were proposed, you argued that doing so precludes the ability to write
mutable implementations. Which is your real argument?
- When we argued about whether or not the URI interface should allow
any request-target, you argued yes; and then you argued, once
implemented, that it should only ever model absolute URIs. Which do
you really want?
- Once we had immutability in place, you then argued, "step back and
look at the 'Identity' of all this [sic] objects". However,
immutability is an implementation detail of value objects, which, by
definition, have identities based on the aggregate of all values they
encompass. Why was identity suddenly a consideration?
- Once we had immutability in place, you stated you are "for and
against immutability, depending on whether it is *conceptionally*
right or wrong."

So, color me confused — you argue for immutability one day, then
against it another day, and mostly against how I've implemented it in
phly/http. I literally have zero idea what your position is, other
than that you're arguing constantly against anything implemented. I
have no idea what would be a conceptionally right use case for
immutability *to* *you*.

And yes, I *have* listened to you. In fact, there's two huge changes
I've made based on your feedback:

- I removed the concept of incoming/outgoing. You were correct: there
are only requests and responses. We *do* need to treat server-side
requests slightly differently, but the basic idea is the two messages.
- Your comments about URIs made a lot of sense when considering that a
client will need the absolute URI (well, the scheme and authority) in
order to make a connection. I wasn't sure how to model this, but Evert
came up with the current implementation, which solves it nicely
(allowing the ability to specify a request-target in the Request,
while still composing a URI).

> You not even try to see how you confuse and harm the whole community with
> this crude and hobbling thing you proposing.

Again, you have not come down with a clear position about what you
find "crude" and "hobbling". My emails to you — on list, on issue
trackers, and privately — have not been met with anything actionable I
can do, and, most often, I'm met with contradictory advice from email
to email I receive from you.

This is why I'm frustrated.

> There are two argument i have seen by you:
> 1. i have tried it for the first time and it was cool
> 2. RTFM
>
> I do understand that it's hard to get things right on first attempt. It does
> not help to be so incredible arrogant, however.
> That you never done this before is not an excuse to wipe away arguments.

And now you have stooped to my own level, which I opened by attacking
you. Again, my apologies.

To be clear:

- I have tried many, many approaches to HTTP messages over my career.
I introduced request and response objects to ZF1 in 2006, worked on
shared interfaces prior to ZF2, helped with the ZF2 HTTP design, and
have been actively working on PSR-7 since last year.
- I've researched HTTP implementations across many languages to
understand which ones work and which ones don't, how they're modeled,
and the ramifications of each.
- Yes, I'm new to *using* value objects, but have been aware of them
and reading about them for around 5 years. I'd not played with the
immutable aspects of them prior to PSR-7, and was actively against the
idea, because I thought it would pose architectural limitations. I
stepped out of my comfort zone when confronted, and tried something
new. I don't always adopt every new thing I try, but I *do* at least
try to understand them. Value objects clicked for me only when I used
them.
- I am actively working towards understanding the ramifications of
value objects for PSR-7, and trying to incorporate feedback. I've
changed my mind and position on various directions of PSR-7 many times
since taking over as editor. I likely will again.

<snip>

> I respectfully ask you to stop bullying around and think about the replies
> in this thread. They are very well thought-out and exactly on point. The
> people know what they are writing about! You need to get this things right
> or you will not only shoot yourself in the foot but the whole community.

I will do so. I also ask that you extend the same courtesy to me.

[Matthew Weier O'Phinney]

On Mon, Feb 2, 2015 at 10:28 AM, Alessandro Pellizzari <al...@amiran.it> wrote:
> On 2015-02-02 14:34, Matthew Weier O'Phinney wrote:
>> On Mon, Feb 2, 2015 at 6:24 AM, Alessandro Pellizzari <al...@amiran.it>
>> wrote:
>>> If immutability is implemented correctly, neither of these will work,
>>
>>
>> Except that PHP does not support immutability at the language level,
>> which means we MUST emulate it.
>
> Is there a better way to implement it (correctly) than the one I wrote?

Since we don't have language-level support, there are multiple ways to
implement it. One is the way I did it in phly/http, where you change
the property value on the clone. This works, as PHP allows changing
private properties of instances of the same class. Is it truly
immutable? No, but it _models_ immutability.

Another is the approach you wrote. It, too, is valid, and keeps the
onus on the implementor and not the consumer (as Larry has noted, any
approach to immutability that requires manually creating new instances
will be too difficult for consumers). Again, because PHP does not
provide immutability at the language-level, it's really not much
different than clone+change, and the end-result is the same. That
said, there's slightly more resource overhead in instantiation than
there is in cloning.

> If you implement public attributes or setAttribute() to be able to clone it
> and mutate afterwards, you are basically declaring immutability "just for
> the sake of it", but not using it correctly.

I'm not defining public attributes at all. As noted, they're private,
which means that consumers cannot make changes to the instance.

> If the language does not allow to implement it efficiently, why define an
> interface that requires it?

For a number of reasons.

We've said from practically the start that the messages are value
objects. At this point, we've take that to the implementation level,
which means a change in any property is a change in the value, and is
thus a new instance.

Doing so provides a number of benefits to architectures that use them.

As an example, how do you know when an actor is making changes to the
value? What if those changes affect your own computations? If the
messages are value objects, changes must be assigned, making them
explicit. Assignment is easy to track down using both static analysis
and step debuggers.

When we consider clients, having value objects makes creating a "base"
request far simpler. In mutable variants, you have to build in
functionality to reset the request to the original state, or to build
a new base request; with value objects, you start with the base, and
any change you want results in a new instance, leaving the base
untouched.

There's many more examples, but the point is that we've identified
problems that are solved by implementing the messages as value
objects.

<snip>

> This is exactly (one of) the reason(s) why I opposed immutability: it's a
> performance killer if implemented correctly in PHP.

We've actually found the opposite (and stated as such elsewhere in
other threads). Operations that result in new instances are measured
in a few dozen NANOseconds. You would need hundreds or thousands of
such operations for it to have any impact on application performance.

[Matteo Beccati]

As far as memory consumption is concerned, all my tests with:

$obj = $obj->withFoo('bar');

show that there should be no overhead.

However that changes if references to the original instances are kept,
for example during a sequence of function/method calls that call some
"with" methods. Due to copy-on-write, each mutation will require less
memory than the original object, but the amount could be non-negligible,
depending on the properties that are changed.

But it's hard to tell without looking at real use-cases, which I haven't
done yet.

[Evert Pot]

Crypto Compress, I think it would be a good time to take a step back
from PSR-7. A lot of discussion has already been had, and this is likely
the type of thing that not everyone will end up loving.

I would kindly ask you to look at the big picture, and consider that
having a PSR-7 in a non-perfect way, is better than not having PSR-7.

I would also want to ask you to try to limit your comments a little bit.
If there are specific things that you think are wrong, it would be a
better to communicate those in the form of concrete suggestions. If you
find that your comments are not ignored or not listened to, then
consider the fact that *everybody* on this list sees your comments,
including all the voting members.

Your voice has been heard, and if the group as a whole deems your
comments to have merit, this *will* come back. Matthew has taken your
comments into consideration (to a fault) and made a decision, as is his
right.

The voting system will decide whether Matthew made the right decision,
and I suspect it will. If your criticism was strong and convincing
enough, then this will also show up during the review phase and voting
phase. I suspect it won't!

I feel for Matthew and understand his frustration quite well, and I'm
not alone in this. You are not communicating well if you are frustrating
the people around you. Matthew is spending a *lot* of his time just
dealing with your comments.

If you can tweak your communication a bit, I know your future comments
will be even more helpful because it's obvious to me that you have a
strong technical background.

Please choose your battles wisely!

Evert

[Crypto Compress]

Hello Matthew,

thank you for this detailed answer!

I am too, very frustrated about this discussion till now. From my
perspective this is the first time i got constructive points to work
with. To fix my contributory fault, i will bring more explanations of my
thoughts and concrete examples.

Not too shure if it's wise to answer inline. However i want to maintain
context and flow of how you see it.

> My point is that nothing, ever, is good enough to meet your standards,
> whatever they are. And you pick and pick and pick at every proposal,
> with very little constructive feedback other than, "this is no good,"
> even when the editors make changes based on your feedback.

One point is, i can't speak in high terms of something, what i see as
"half done".
The other point is, we seem to talk at cross purposes. I hope to
mitigate this by being more exact on what my intentions are.

> I'm asking for you to engage in the spirit of consensus, and not to
> just pick everything apart.

Not shure if i can do this. I need to disassemble all the things first
to get (better) overview. However i will try to express my findings
better/more positive.


> Which misinterpretations and misconceptions?

Not conducive to answer this. I am not shure i will answer this at all
but if then in a separate post.

> - When we implemented URI interfaces, we specifically indicated they
> would only model web-based URIs: i.e., HTTP or HTTPS. But then you
> asked why it doesn't allow for mailto: schemes.

I have not seen this point at that time, so i asked. Not modeling other
schemes is focused, right and good.

> - When we implemented a URI interface, and explicitly stated it was to
> model only web-based URIs (just as we did with streams), to allow us
> to model URIs for the purposes of HTTP messages, you then argued for a
> new general-purpose PSR for URIs.

We don't need all the features of general-purpose URIs in this PSR. Any
other PSR is out of scope. Sorry that/if i brought that up.
To clarify, my point is about strict handling of uris (http, https).

When saying "strict", in http-uri-interface context, i think of following:
* check scheme (scheme, to determine default port)
* check on non-empty host
* check on non-empty path
This checks should be the default and only for the special edge cases,
it should be allowed to skip them.
* provide/abstract parsing methods
* and access to all parts (forms, query params, ...)
Encourage unified access to all parts of URI through the instance of
UriInterface. So we don't need access to superglobals anymore.

This points should ensure that a typehint on UriInterface is expressive:
* function foo(UriInterface $uri) { ... } // i have a valid uri with all
needed parts and can transform to any form and get any single part
Currently, as i know, this typehint indicates only that i will get a
not-null string. Correct me if i'm wrong.

clear position: I think URIs have to be strictly immutable.
The rest of "(im)mutable" i have to omit here (better handled below).

I hope the main points are better visible now. If this is misleading or
ambiguous please say so. I will try to clear every aspect.
(there will be a point about new/current implementation below)

> - When asked about immutability or selected mutability, you replied
> off-topic by asking what the interfaces *do* (when they have been
> described all along as value objects, and not objects with behavior).

I can't follow you here. For me, every object can be immutable no matter
if VOs, Entities, services, flyweight, ...
The main point is to _not_ provide any methods that can change inner
values. This point is not about set vs. with. I think this is not about
behavior too.

Maybe an example is better suited:
In my domain i need to design two big corporations. With all the inner
values like employees, locations, buildings, subsidiaries, what so ever.
The first corporation is Sun Microsystems and the second is Oracle. It
would be strange to see new employees appear in an object modeling Sun
and common at Oracle.
The point about interfaces is, that both are corporations and i want to
typehint somewhere else on CorporationInterface. In this place i can
only rely on the immutable part.

I am sure this is not enough of an explanation. More to follow.

> - Again, when asking about immutability, you then changed the topic to
> ask about the lifetime of the message objects, with no context about
> why this was relevant to the discussion. You brought it up again once
> selective mutability was implemented, and stated that "this is
> crucial."
> When I and others indicated the way current frameworks work
> and what we're targeting (requests are referenced throughout the
> application request cycle, as are responses), you argued they
> shouldn't be, but would not provide counter-examples to show the
> application workflow you envision.

I have looked up this emails and have to admit, the context is missing
completely.

This whole thing is way too big and it's too late to reason it out. Here
are only some bullet points:

* lifetime of objects
** Information passed in from extern is long-living and immutable.
Configuration or an incoming request on the server are examples for
this. I do not differentiate them and refer to both as configuration.
** Long-living mutable objects are global state.
* calling tree/stack trace: short-living mutable objects are created and
destroyed all over the place
* construction graph: no mutable objects present at all

Sorry, i can't make my point clear on this. Not even sure it's
beneficial to this PSR as it's a bigger picture. I have to rethink if i
want to reason about this at all.

> - When asked what the pros/cons of immutability would be, you argued
> mutable is a superset of immutable, and argued to remove
> incoming/outgoing interfaces. And then later, when immutable instances
> were proposed, you argued that doing so precludes the ability to write
> mutable implementations. Which is your real argument?

Sorry for confusion. This are different points in different context.
Please see below.

> - When we argued about whether or not the URI interface should allow
> any request-target, you argued yes; and then you argued, once
> implemented, that it should only ever model absolute URIs. Which do
> you really want?

Both. UriInterface derive request-target from absolute uri.

> - Once we had immutability in place, you then argued, "step back and
> look at the 'Identity' of all this [sic] objects". However,
> immutability is an implementation detail of value objects, which, by
> definition, have identities based on the aggregate of all values they
> encompass. Why was identity suddenly a consideration?

The point about Identity is a helper construct to split VOs and
Entities. As pointed out above, both can be (im)mutable.
* In current context all VOs are immutable. This is uncontroversial
(edge cases are offtopic).
* Whether Entities should be (im)mutable is highly context dependent.
Remember the example with corporations.
As i see it, "Request" and even more "Response" are Entities. A client
requests a resource on a php server and identifying this resource with
an Uniform Resource Identifier. This word "Identifier" is very specific
and as we design not-on-wire-message we can use this URI as the
entity-identifier.

The point about Entities deserves an extra post however.

> - Once we had immutability in place, you stated you are "for and
> against immutability, depending on whether it is *conceptionally*
> right or wrong."

Okay, here we go!
In my eyes immutability is not bound to some technical concept.
Immutability is always a requirement of the domain. It's even more
profound, all state existed previously in time is immutable. If we
mutate previously existing objects, we timetravel and kill our
grandfather. Sounds wired, but that's the point.
(configuration, life-time of objects, ex-something)

* Request to server is configuration from past time and immutable
* Responses need to be build up thus mutable
(and vice versa for request build up incrementally and response immutable)

> So, color me confused — you argue for immutability one day, then
> against it another day, and mostly against how I've implemented it in
> phly/http.

The implementation in phly/http has it's assets and drawbacks. (This is
not about (im)mutability.)
* asset: pass-by-reference-semantics are jimmied. Many current designs
mutate state all over the place. To allow them to do this without any
side effects, is a clear win.
* drawbacks: To get the desired changes back, we are now bound to a hard
coded return type. If we have some other infos to return, we need to
hack around this return type (effects: attributes, or "return
array($responseClone, $otherInfos)"). There is the functional way to
handle this with a deep call-tree. However i don't know how well php
will handle this. This is currently a quite uncommon approach in the php
world.

This is too vague to be useful. Sorry. I need to get better example for
this.

> I literally have zero idea what your position is, other
> than that you're arguing constantly against anything implemented. I
> have no idea what would be a conceptionally right use case for
> immutability *to* *you*.

The right thing for me™:
* "strict" uri as a default
* anything incoming immutable
* anything outgoing mutable
* immutable as "do not provide any mutators at all"

> And yes, I *have* listened to you. In fact, there's two huge changes
> I've made based on your feedback:
>
> - I removed the concept of incoming/outgoing. You were correct: there
> are only requests and responses. We *do* need to treat server-side
> requests slightly differently, but the basic idea is the two messages.

Don't know what to say.

> - Your comments about URIs made a lot of sense when considering that a
> client will need the absolute URI (well, the scheme and authority) in
> order to make a connection. I wasn't sure how to model this, but Evert
> came up with the current implementation, which solves it nicely
> (allowing the ability to specify a request-target in the Request,
> while still composing a URI).

I don't grasp this concept. This was new to me and more of a hack.

> Again, you have not come down with a clear position about what you
> find "crude" and "hobbling". My emails to you — on list, on issue
> trackers, and privately — have not been met with anything actionable I
> can do, and, most often, I'm met with contradictory advice from email
> to email I receive from you.

I don't think i will ever come up with actions you can do. I am not your
boss. Sorry for failing to explain my thoughts. I try...

> This is why I'm frustrated.

I understand now.

> And now you have stooped to my own level, which I opened by attacking
> you. Again, my apologies.

Accepted. Please excuse me too.

> - I have tried many, many approaches to HTTP messages over my career.
> I introduced request and response objects to ZF1 in 2006, worked on
> shared interfaces prior to ZF2, helped with the ZF2 HTTP design, and
> have been actively working on PSR-7 since last year.
> - I've researched HTTP implementations across many languages to
> understand which ones work and which ones don't, how they're modeled,
> and the ramifications of each.
> - Yes, I'm new to *using* value objects, but have been aware of them
> and reading about them for around 5 years. I'd not played with the
> immutable aspects of them prior to PSR-7, and was actively against the
> idea, because I thought it would pose architectural limitations. I
> stepped out of my comfort zone when confronted, and tried something
> new. I don't always adopt every new thing I try, but I *do* at least
> try to understand them. Value objects clicked for me only when I used
> them.
> - I am actively working towards understanding the ramifications of
> value objects for PSR-7, and trying to incorporate feedback. I've
> changed my mind and position on various directions of PSR-7 many times
> since taking over as editor. I likely will again.

Thank you for your work. I have used ZF since 0.8 (?) so some of this
happened right in front of my eyes.

> I will do so. I also ask that you extend the same courtesy to me.

Fair deal.



I am very happy about concrete questions i can try to find answers for.
It's only to much at once. Will work out some of this things better. Any
suggestions where to start?

[Alessandro Pellizzari]

On 2015-02-02 16:53, Matthew Weier O'Phinney wrote:

> Since we don't have language-level support, there are multiple ways
> to
> implement it. One is the way I did it in phly/http, where you change
> the property value on the clone. This works, as PHP allows changing
> private properties of instances of the same class. Is it truly
> immutable? No, but it _models_ immutability.

I thought it was a bug exploit, but I found the part in the manual
where it says it's a wanted behaviour.
Their explanation makes sense, even if I still don't know how I feel
about it.

Anyway, my opposition based on performance has no more reasons to
stand.

> We've said from practically the start that the messages are value
> objects. At this point, we've take that to the implementation level,
> which means a change in any property is a change in the value, and is
> thus a new instance.

I missed the part where they were defined as Value Objects, sorry.
But I don't think they are.

A Value Object should be small and represent a single value. DateTime
is a Value Object. A Request is not. It includes hundreds of values.
A Response is definitely not a Value Object. It gets constructed step
by step by the application.
An outgoing Request is the same.

I know you removed the distinction betweek outgoing and ingoing, and I
agree. But this should make them both mutable, not immutable.

> As an example, how do you know when an actor is making changes to the
> value? What if those changes affect your own computations? If the
> messages are value objects, changes must be assigned, making them
> explicit. Assignment is easy to track down using both static analysis
> and step debuggers.

My point is: you should not care who changes it.

As I said, if a "cookie decrypter" needs to change the headers, it
needs to change them. And it needs to change the Request.
If a component changes a Request and you don't want it to do it, don't
use that component.

> When we consider clients, having value objects makes creating a
> "base"
> request far simpler. In mutable variants, you have to build in
> functionality to reset the request to the original state, or to build
> a new base request; with value objects, you start with the base, and
> any change you want results in a new instance, leaving the base
> untouched.

If a component needs to create multiple requests with just one field
changed (a URL harvester, for example) it will clone them by itself and
change the clones.
This also gives much more control on memory management and on work
distribution (multithreading, distributed processing, etc.)

> There's many more examples, but the point is that we've identified
> problems that are solved by implementing the messages as value
> objects.

I think immutability, in this case, tries to protect the developer from
himself, and that is a thing I, as a developer, hate in a framework.

Bye.

[Crypto Compress]

> To clarify, my point is about strict handling of uris (http, https).
>
> When saying "strict", in http-uri-interface context, i think of
> following:
> * check scheme (scheme, to determine default port)
> * check on non-empty host
> * check on non-empty path
> This checks should be the default and only for the special edge cases,
> it should be allowed to skip them.
> * provide/abstract parsing methods
> * and access to all parts (forms, query params, ...)
> Encourage unified access to all parts of URI through the instance of
> UriInterface. So we don't need access to superglobals anymore.
>
> This points should ensure that a typehint on UriInterface is expressive:
> * function foo(UriInterface $uri) { ... } // i have a valid uri with
> all needed parts and can transform to any form and get any single part
> Currently, as i know, this typehint indicates only that i will get a
> not-null string. Correct me if i'm wrong.

Hi,

two points:

1) Using "sane defaults" is better then to water the "strictness" of
UriInterface down.
- if scheme is unavailable it should be okay to assume "http"
- if host is unavailable then it should be okay to insert a "sane
default" of "0.0.0.0"
- if path is unavailable it's okay to assume "/"

2) UriInterface should provide abstraction for creating url encoded
data. (I think about a stateless encodeQueryParams(array $keyValue) method.)
- url encode query params
- proper encode multibyte values
- it's a quick interoperability win
http://www.w3.org/TR/html5/forms.html#url-encoded-form-data

cryptocompress

[Crypto Compress]

A very interesting read related to "construct and/or clone" topic:
http://www.agiledeveloper.com/articles/cloning072002.htm

[Matteo Beccati]

On 14/02/2015 08:38, Crypto Compress wrote:
> A very interesting read related to "construct and/or clone" topic:
> http://www.agiledeveloper.com/articles/cloning072002.htm

I didn't know that PHP had final properties ;)

[Crypto Compress]

Am 14.02.2015 um 17:30 schrieb Matteo Beccati:
> On 14/02/2015 08:38, Crypto Compress wrote:
>> A very interesting read related to "construct and/or clone" topic:
>> http://www.agiledeveloper.com/articles/cloning072002.htm
>
> I didn't know that PHP had final properties ;)
>
>
> Cheers

Yes, PHP has no final props and no method/constructor-overloading. So
implementing with*() methods with clone is appropriate.