Port TypeParser to Hoa\Compiler

[Majkl578]

Q	A
Bug fix?	no
New feature?	no
Doc updated	-
BC breaks?	yes
Deprecations?	no
Tests pass?	yes
Fixed tickets	#892

This is a port of TypeParser to Hoa\Compiler. It is entirely independent on legacy and abandoned jms/parser-lib.no
It's currently built on top of current TypeParser to achive & present the prototype and compatibility - this way it can be tested and used even on 1.x. (I won't be rebasing this on top of 2.0 PR.)

Includes/TODO:

• grammar
• parser (re)generator
• legacy visitor used as a compatibility hack for 1.x
• AST visitor to build AST tree of the type definition
• AST-based manipulation in consumers
• replacing occurences of the old TypeParser with the new Parser
• dropping old TypeParser

Would love to hear some opinions / feedback. 😎

PHP <7.1 tests will be failing because of the PHP 5.x/7.0 madness.

[Majkl578]

Rebased onto current master (2.0), dropping old TypeParser completely.

It serves as a drop-in replacement of old TypeParser now.
Further scope is to eliminate those arbitrary array definitions of types used everywhere. :/ Likely in separate PR.

[goetas]

Just to understand better hoa compiler, has this code present in this PR to be "maintained" of is automatically generated by HOA? (currently to me it seems a lot of "mysterious" code landing in the main repo...)

[goetas]

What about the phpunit warning/failure?

[Majkl578]

Updated.

• Removed AST and only keep current legacy array format for types. (Likely to be rescheduled for 3.0.)
• Added parser interface (it'd be easy to add some memory or advanced cache layer).

has this code present in this PR to be "maintained" of is automatically generated by HOA?

Regarding parsing itself, the burden is to maintain grammar.pp and TypeVisitor. InnerParser is generated code by Hoa state exporter.

What about the phpunit warning/failure?

The one there is caused by lowest deps of Hoa Compiler itself, likely dependency issue on their side. :/

[Majkl578]

Reported here: hoaproject/Compiler#83

[Majkl578]

Right, for now I added conflicts with incompatible lowest deps, that should be good enough.

[goetas]

can you rebase this please?

[Majkl578]

done

[goetas]

Did some benchmarking...

$typeParser = new \JMS\Serializer\Type\Parser();// HOA
$typeParser = new \JMS\Serializer\TypeParser(); // current parser
///
$typeParser->parse('array<string, User>');
$t = microtime(true);
for ($i = 0; $i < 100000; $i++) {
    $typeParser->parse('array<string, User>');
}

var_dump(microtime(true)-$t);

Results:

float(0.58429503440857)
float(10.030526161194)

Not that fast 😞

[Majkl578]

a) you are not going to parse a type 100000x, not even 10000x, 1000x, maybe 100x
b) result is to be cached as part of Metadata anyway so this shouldn't be an issue
c) ParserInterface gives another opportunity for CachedParser (on different level than Metadata)

[goetas]

Out of curiosity, which versioning scheme does HOA follows? Is this some kind of 3.x?

[Majkl578]

If I understand correctly, it's <major>.<releaseyear>.<releasemonth>.<releaseday>. Looks pretty weird, but incidentally works with semver. 😂

[goetas]

Even if performance wise there is a drop of 2% on a single iteration, there are advantages with using a AST based parser. Plus having JMS\Serializer\Type\ParserInterface allow us to change in the future the compiler implementation if necessary