{"action":"created","issue":{"url":"https://api.github.com/repos/phly/http/issues/58","labels_url":"https://api.github.com/repos/phly/http/issues/58/labels{/name}","comments_url":"https://api.github.com/repos/phly/http/issues/58/comments","events_url":"https://api.github.com/repos/phly/http/issues/58/events","html_url":"https://github.com/phly/http/issues/58","id":70914087,"number":58,"title":"again about returning clones","user":{"login":"pine3ree","id":3229979,"avatar_url":"https://avatars.githubusercontent.com/u/3229979?v=3","gravatar_id":"","url":"https://api.github.com/users/pine3ree","html_url":"https://github.com/pine3ree","followers_url":"https://api.github.com/users/pine3ree/followers","following_url":"https://api.github.com/users/pine3ree/following{/other_user}","gists_url":"https://api.github.com/users/pine3ree/gists{/gist_id}","starred_url":"https://api.github.com/users/pine3ree/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/pine3ree/subscriptions","organizations_url":"https://api.github.com/users/pine3ree/orgs","repos_url":"https://api.github.com/users/pine3ree/repos","events_url":"https://api.github.com/users/pine3ree/events{/privacy}","received_events_url":"https://api.github.com/users/pine3ree/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"milestone":null,"comments":3,"created_at":"2015-04-25T13:58:27Z","updated_at":"2015-04-29T14:49:41Z","closed_at":"2015-04-25T17:47:44Z","body":"HI @weierophinney ,\r\n\r\ni noticed that in case of no state change you still return a cloned instance:\r\n```php\r\n// ex. Uri::withScheme(...)\r\n// Do nothing if no change was made.\r\nreturn clone $this;\r\n``` \r\nIn my opinion (i wrote/asked about this somewhere else) since the instance does not change we could simply return $this. This does not affect immutability.\r\n\r\nI missed this point (basically what i was asking about and i never noticed, or maybe it was added later) before in the specs but:\r\nhttps://github.com/php-fig/fig-standards/blob/master/proposed/http-message-meta.md \r\nparagraph : New instances vs returning $this\r\n\r\nseems to approve returning just $this."},"comment":{"url":"https://api.github.com/repos/phly/http/issues/comments/97454342","html_url":"https://github.com/phly/http/issues/58#issuecomment-97454342","issue_url":"https://api.github.com/repos/phly/http/issues/58","id":97454342,"user":{"login":"weierophinney","id":25943,"avatar_url":"https://avatars.githubusercontent.com/u/25943?v=3","gravatar_id":"","url":"https://api.github.com/users/weierophinney","html_url":"https://github.com/weierophinney","followers_url":"https://api.github.com/users/weierophinney/followers","following_url":"https://api.github.com/users/weierophinney/following{/other_user}","gists_url":"https://api.github.com/users/weierophinney/gists{/gist_id}","starred_url":"https://api.github.com/users/weierophinney/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/weierophinney/subscriptions","organizations_url":"https://api.github.com/users/weierophinney/orgs","repos_url":"https://api.github.com/users/weierophinney/repos","events_url":"https://api.github.com/users/weierophinney/events{/privacy}","received_events_url":"https://api.github.com/users/weierophinney/received_events","type":"User","site_admin":false},"created_at":"2015-04-29T14:49:41Z","updated_at":"2015-04-29T14:49:41Z","body":"@pine3ree —\r\n\r\n> \"don't do any movement unless you really need to\". So to me, even if an operation does not cost so much, it's always preferable not doing it unless it's really needed.\r\n\r\nOne concern I look at, though, is complexity. Adding _any_ conditional into a method increases complexity, and requires additional test cases to ensure behavior is as expected for the new execution paths. As such, there's a *maintenance cost* to the operation. As a developer, I have to weigh both. I've chosen to reduce the complexity to ease maintenance.\r\n\r\n> any reason to keep members (like $queryParams, $attributes in ServerRequest) private in your http-message implementation?\r\n\r\nMarco Pivetta (@Ocramius) has convinced me over the years that it's the onus of users to provide concrete use cases for loosening visibility. By declaring the members private to begin with, users can be assured that operations will work as specified, even in class extensions; if they are protected or public, it's possible the extension is altering the behavior in unexpected ways. As such, keeping them private is ideal, *until a demonstrated, general-purpose use case is presented*.\r\n\r\nIf you need to read or alter private properties, Marco has blogged on how to do so: http://ocramius.github.io/blog/accessing-private-php-class-members-without-reflection/"}}