Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[PSR-7] Adding a Errata section to PSR-7 to clarify UriInterface modification mechanism #619

Closed
wants to merge 1 commit into from
Closed

[PSR-7] Adding a Errata section to PSR-7 to clarify UriInterface modification mechanism #619

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
9 changes: 9 additions & 0 deletions accepted/PSR-7-http-message-meta.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -647,3 +647,12 @@ used to populate the headers of an HTTP message.
* Anton Serdyuk
* Phil Sturgeon
* Chris Wilkinson

## 7 Errata

### 7.1 Invalid `UriInterface` after modification (2015/09/02)

Supplying a valid value to a `UriInterface` modifying method does not guarantee that the resulting `UriInterface`
object will generate a valid URI string. Because no exception can be thrown in a `__toString` method, the invalid
URI string can only be detected when the new instance is created. In such situation, a `RuntimeException` exception
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How I understand is, that the RuntimeException may be thrown in the constructor of an URI implementing UriInterface, right?
I think the mention of the RuntimeException does not make sense here as PSR-7 does not specify the constructor at all. So the constructor can throw any exception and is implementation-specific.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The exception could also be thrown with the modifying methods too. Since with* return a new/clone methods with the modified information.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMHO it's a value object so no 'domain' logic inside. Exception should be thrown only by the objects which use it.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a value object so it should validate its properties on construction. Otherwise it is not a value object. The modifying method generate a new object so the resulting properties should be validated indivdually and against each other to ensure the value object is valid.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It all depends on the complexity of the domain model. For a simple model validation can be inefficient and unnecessary. For areas more complex you can avoid duplication of code in the other components by using the decorator:

class ValidUri implements \Psr\http\Message\UriInterface {
     / **
      *   throws \DomainException
      * /
     public function __construct (\Psr\http\Message\UriInterface $uri)
     {
     }
}

In summary, I think the standard should not be forcing customers.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@krzysiekpiasecki the issue is that you seem to think that an URI is a simple model, which is not (rfc3986 contains around 60 pages!!). I don't understand the added value of a decorator please check my simple example

use Zend\Diactoros\Uri;

$uri = new Uri('http://www.example.com');
$invalidUri = $uri->withHost('')->withPath('foo/bar');

echo $invalidUri, PHP_EOL; // returns http:///foo/bar

What would a decorator adds or simplify ? using UriInterface::withPath should thrown an exception.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the issue is that you seem to think that an URI is a simple model

I mean the application model.

Very simple application with one component using URI and complex application with many components using it. In simple cases i prefer for example 'filter_var' and also add my own validation rules, etc.

I don't understand the added value of a decorator
What would a decorator adds ?

  • Constitues and extracts custom validation layer,
  • No duplication in complex model, when value object is not validated by itself, but components must relay on him.

As I sad it's only my opinion about this errata :)

Regards

may be thrown to indicate an invalid URI on runtime.