Add nested ranges

[appeltaert]

I'm currently falling back on PHP alot because of the amount of nested looping i need to do to keep fixtures as dry as possible.

foreach($contentTypes as $type) {
    $return['Content']['content_'.$type.'{1..5}'] = [
        // ...
        'ctype' => '@ctype_' . $type
    ];
}

In YML this currently means:

Content:
    content_image_{1..5}:
        ctype: '@ctype_<current()>'
    content_video_{1..5}:
        ctype: '@ctype_<current()>'
    [...]

Could possibly be written as:

Content:
    content_{image, video}_{1..5}:
        ctype: '@ctype_<it|current|arg(1)>'

[theofidry]

Sorry for the lack of feedback I completely missed the issue. I think that's a cool idea, I don't think I'll have time to work on it but it would be interesting to try to integrate it before the stable release, to see if the system is flexible enough for this kind of customization.

[appeltaert]

No prob, i can take a look at it, this or the next week

[appeltaert]

So i did some eyeballing, and while its not a terrible lexer, i think(not an expert) this feature requires a LL(k) parsing pattern to solve elegantly, and like you suggested yourself, #601 supports it.

I think this is a good move, a lot of open issues/tasks i saw on that 3.0 road map involves the lexer also right? Chances are that most new features/changes are going to involve the lexer.

[theofidry]

I think this is a good move, a lot of open issues/tasks i saw on that 3.0 road map involves the lexer also right? Chances are that most new features/changes are going to involve the lexer.

Hm not so much actually. The lexer is involved as soon as something touches the Expression Language, i.e. the syntax to declare values. The parsing for the IDs or class names is done by the FlagParserInterface, which does not involve the lexer but good old regexes (which is more than enough there).

The main features left on my side:

• Some benchmarking to see if there's things to improve and give the possibility to any contributor to quickly do a profile if he wants to check himself
• Fix any obvious bottleneck
• Finish Fixture lifecycle #388
• Finish the doc
• Check if we can do a caching of some sort:
  • Caching the fixture set resulting from the FixtureBuilder (see https://github.com/nelmio/alice/blob/master/CONTRIBUTING.md#fixturebuilder), which is invariant
  • Caching the generated set. In some cases you don't want to generate a new one with different values (as you may not care), which would greatly improve performances for HautelookAliceBundle for example
• A few other issues left and right

[theofidry]

There is a few features I'm not aiming for the 3.0 stable release: if someone is ready to work on them before that I would welcome it obviously, but it's not my priority/goal.

I would love #601 to be done before the stable release as well, but I have little time to investigate how it would work (the list above is already more than enough :P)

[appeltaert]

I totally missed contrbuting.md, i'll put some more time in into this. It is possible that it takes someone more acquainted with the internals to really pick this up, but its still a fun introduction to the internals.

[theofidry]

It is possible that it takes someone more acquainted with the internals to really pick this up

For now there's only me 😛 I realise it's a big library which makes it not very easy to dig it, but I tried my best to make the code and doc regarding it as clear as possible. If you find something confusing while looking at something, don't hesitate to report it!