All validate_* methods should be marked @internal or @deprecated with a note saying that in 4.0 they won't be public anymore.

About the validate() method, I don't really like how it works now. I think that all should validate everything.

Maybe we can work 2 arrays:

• An array of validators (Should be a callable, [$this, 'validate_enable'] per example)
• A map associating a target to a list of validators
  Then when validate($a) is called, we check if there is a such target or if there is a such validators and then we call them.

e.g:

$validators = [
    'enable' => [$this, 'validate_enable'],
    'dir' => [$this, 'validate_dir'],
];

$map = [
    'all' => ['enable', 'dir'],
    'display' => ['enable'],
];

function validate($target)
{
    $v = isset($map[$target]) ? $map[$target] : (array) $target;

    foreach ($v as $validator) {
        $validators[$validator](); // Plus handle faillure or anything else if necessary
    }
}

I like your proposal. If we are refactoring validate completely, maybe worth adding a validation (and get) for version_check, quite used in the code.
Will work on this.

While we are at this, what do you think about making metadata completely "opaque", that is, encapsulated by extension manager, using it as the only accessor to metadata manager, providing proxy methods in extension manager to validate and get metadata? That would be a separate (but related) PR. Same thing could be done for extension objects themselves (only is_enableable is accessed from outside of the direct control of extension manager).

Ok, I have the code, as follows:

1. Create a single array, as a class property, filled in the constructor (extending the existing one, but moving it to a class property and initializing once)
2. Array key is the validation name, array value is mixed, as follows:
   • null for callable methods, of the form 'validate_'$key
   • string for reg exp validation of regular fields
   • array for combined validation by nesting (self calling)
3. The validate function accesses the array, and determines how to proceed:
   • calling the specific function
   • performing the regular expression check
   • self-calling with the component validations
     Is this the right approach?

I could revert back to three arrays, but would be as complex, and more verbose... Your choice :)

As for the other comment, I will mark all validate_ methods as internal (not deprecated) as they will continue existing, although moving them to protected visibility (as of 4.0, right?).

For now, I have not changed the semantics of any validation (all is display + enable, so really, all things that are validated are included here).

Lets see how it looks.

About merging the extension manager and the metadata manager I think it is a bad idea, lets keep concerns separated (I think we even should move the validation to another class)

Three commits:

1. New validate method (will change the array initialization to static)
2. Include the "internal" message into the docblocks, please review if ok
3. New method for version_check (maybe it should be a separate PR?)
   Note that this is not yet 100% complete: I want to review the uses of check_version from acp_extension and check CLI command, and may want to adapt to use the new validation option (will work as is, but might be better to update it).

Regarding merging extension manager and metadata manager, I think I miss-explained what I meant.
I do NOT want to merge both. I just want to make any direct access to metadata manager redundant, as it may be accessed through the extension manager as a proxy for md mgr. They are always used together, so why not use just one as the single interface? Also, having the metadata cached (lazy loaded) in extension manager as we have it now, it is clean to access it that way. Anyhow, definitely, a separate PR would be required.

@Nicofuma completed what we talked about:

• validations array is now static (accessed through self::, maybe we should use static:: instead?)
• validate_version_check is also complete, and cleaned the uses of it in acp_extensions and cli/check, plus the use in ext_manager that was already completed

Anything else you think is worth doing here?

About making the validation a new class... I don't think so: it is heavily mixed with the getter methods for metadata elements. But maybe we could create a trait as a design pattern for validation, that just entering the array as static would validate in any of the three available ways: string pattern, function and combined, or even think of more validation methods...

@Nicofuma Anything else left to do here? Is this going forward?