Reimplement JsonMapper

[reimic]

Reimplements parts of the Json Mapper to work in PHP == 7.0 and use less dependencies.

• Reimplements only the most crucial parts of the jsonmapper/jsonmapper dependency.
• Reworks Middleware and Handlers into simpler Evaluators. Instead of relying on magic methods for Handlers, a simple loop is run to go through all Evaluators.
• Reworks Evaluators to auto-configure just before mapping, not during initialization, as was the case prior to this PR. JsonMapper used to resolve all Handlers during initiation, later checking if the resolved values are still available when mapping methods were called. This caused some code to be run during container preparation. This was altered to configure at first map_to_class call, thus no mapper-related code is run before JSON input validation succeeds.
• Deletes the nonessential Evaluators convenience builder, still preserving elasticity for new Evaluators.
• Converts Enums to internal lists and strings. Enums were a separate dependency which required PHP > 7.0 and provided little utility. This relates to ScalarTypes and Visibility classes.
• Joins PropertyMapper, ValueFactory, FactoryRegistry and ScalarCaster into a single streamlined class.
• Internalizes some small utility methods to reduce class overengineering.
• Simplifies recursivity.
• Refactors all code to run with PHP == 7.0.
• Deletes all implementation parts that evaluated void, mixed , unions and etc. Since this mapper will only ever map to classes that are PHP 7.0 compliant.
• Adds tests.

[adamziel]

Why is this needed?

[reimic]

I'll remove remove_utf8_bom() for now.

However there are 2 aspects here. I think each deserves an issue of its own.

1. I've encountered multiple problems with json_decode(). It was very sensitive to a bunch of things related to Windows end line characters and general formatting. This should be looked at as a semantically and syntactically valid JSON might be provided, but some miniscule formatting issues will cause it to fail at decoding. Should be reviewed before v1.
2. Despite the above. It will always be possible that the JSON will me in some shape or form syntactically malformed. In such cases json_decode() returns null and json_last_error() can be called to get more information on what actually transpired. I've added the most basic Malformed JSON. message, just to signify the issue was syntactic, not semantic in nature. But I know from experience this is one of the most frustrating parts of using a new API. If we truly aspire to deliver a premium way of setting up/developing WordPress, providing a robust troubleshooting experience is paramount. That said, this is not a v1 deployment-blocking issue.

[adamziel]

Would you please start a new issue with the problem description and reproduction steps?

[adamziel]

I left some notes, but things are mostly looking good. Yay! Thank you for you great work on this! I'd love to also see some more tests around:

• Arrays
• Union types
• Nullable and missing properties

For example, the following Blueprint should be correctly mapped even though the array contains two different data types:

{
	"plugins": [
		"https://downloads.wordpress.org/plugin/wordpress-importer.zip",
		{ "resource": "url", "url": "https://mysite.com" }
        ]
}

However, this Blueprint should be rejected since numbers are not valid as a plugin definition:

{
	"plugins": [
		"https://downloads.wordpress.org/plugin/wordpress-importer.zip",
		123
        ]
}

[reimic]

I left some notes, but things are mostly looking good. Yay! Thank you for you great work on this! I'd love to also see some more tests around:
...
Union types

I do not see how union types play into this - they are not a PHP 7.0 thing. I would imagine we should just not use them anywhere in the lib.

[reimic]

I left some notes, but things are mostly looking good. Yay! Thank you for you great work on this! I'd love to also see some more tests around:
Arrays
Union types
Nullable and missing properties

Most definitely. I do have quite a lot of tests in mind. How would you like to progress from here: test the mapper now or merge it, finish other downgrade-related matters and than circle back?

I'd recommend the latter. I think, and this is also reflected in your comments, there are still some things we can iterate upon. A testing-focused PR done in a week or so would be a great occasion to go through everything and make some improvements with "fresh" eyes.

[adamziel]

I do not see how union types play into this - they are not a PHP 7.0 thing. I would imagine we should just not use them anywhere in the lib.

Types are expressed either as type annotations or as comments. Union types are all over Blueprints, e.g. ResourceInterface|string, they're just stored in comments since PHP 7.0 doesn't support them. Ditto for typed collections like string[].

[adamziel]

Let's test the mapper now to make sure it actually works. It's a central, critical part of the system. Breaking it would generate more work with debugging, reverting this or etc.

[reimic]

@reimic the PR description covers a delta between the JsonMapper library and this PR. It would be more useful if it instead discussed the problem being solved, gave a short overview of the solution, and provided testing instructions.

Fair point. I'll do one, after all threads are resolved.

[adamziel]

Let's get this in! @reimic would you please update the description for any future readers as discussed earlier?