Migration questions

[kynx]

Couple of things I'm not 100% about:

• I see $services->get('Config') in lots of v2 packages. In Expressive "config" is lowercased. I'm guessing it should be lowercased to make it compatible with both v2 and v3. Can you confirm?
• There seem to be endless variations of alias formats for plugin managers. The docs have alllower, camelCase and CamelCase, but test cases for lots packages (esp. those dependent on zend-validator) use a lot of snake case in the config ('not_empty', 'string_trim', etc). Should the tests change, or the aliases?
• The docs for AbstractPluginManager have the validate() method throwing an InvalidServiceException. Most packages throw their own exception from validatePlugin(). Is the intention that all v3 packages use the InvalidServiceException (in which case validatePlugin() should catch and re-throw), or is it OK to throw the package-specific exception from validate()?

Many thanks!

[Ocramius]

I see $services->get('Config') in lots of v2 packages. In Expressive "config" is lowercased. I'm guessing it should be lowercased to make it compatible with both v2 and v3. Can you confirm?

I think the casing should be "Config", as packages relying on v2 currently ->get('Config') (most of them, at least), and they will break when changing to config.

Changing everything to lowercase may simplify things though...

Should the tests change, or the aliases?

Tests shouldn't change, as that makes it even more complex to deal with BC. The aliases should be adapted, IMO.

is it OK to throw the package-specific exception from validate()?

Yes, but only if it still respects the signature of the service manager (must be a subtype of any of the @throws documented there)

[bakura10]

In v2, because of the normalization, "Config" is actually transformed to "config" in all cases. But v3 no longer normalizes any thing, so it was decided to use the simplest "config" (as it was stored in v2 after normalization).

[kynx]

Thanks @bakura10 - so for forward compatibility we should be changing it to "config" where used inside plugin managers, etc?

[kynx]

Thinking about it in light of #81 (and keep in mind it's late) I think it would make more sense to have the aliases all lowercase for forward compatibility. SMv2 is going to be happy with that and it can be documented as a BC break for V3.

Factories will need two entries::

    protected $factories = [
        Class:class => InvokableFactory::class,
        'namespaceclass' => InvokableFactory::class,
    ];

Tests will need to be updated were they use old-style aliases in v3. Is there any easier way to detect the version, other than property_exists($services, 'serviceLocator')?

[weierophinney]

@kynx These are all sorted now with the latest patches I've merged from you, are they not?

[kynx]

Yup! Will be updating my migration PRs later.