composer autoloading

[cordoval]

note: transferred from https://github.com/cordoval/hamcrest-php/issues/10

At the moment I can put a require in my tests or using composer I can add the files array to composer.json.

"autoload": {
     "files": [
            "vendor/cordoval/hamcrest-php/hamcrest/Hamcrest.php"
        ]
}

Is there a plan to convert this to a class so namespacing can be used?

[cordoval]

transferring history of discussion

davedevelopment:

:-1:

This dumps functions in the global namespace, which and could cause trouble for anyone with the functions in the global namespace already.

@aik099:

I also don't like that. That's why in long term I plan to create a special test case class for PHPUnit, that would fuse PHPUnit's own matches & assertThat with ones, that Hamcrest have.

This way $this->isAnyOf would use Hamcrest matcher in PHPUnit test and $this->assertThat would also accept Hamcrest matcher as input and not only PHPUnit's one.

Hopefully there won't be any naming conflicts, but if they would, then they would be resolved in favor of PHPUnit's match if a functionality is identical.

Not sure though, when I have the time to implement this idea.

@aik099:

The funny part is, that Hamcrest stuff itself is already OOP, but this Hamcrest.php file is created just as universal plugin to any test framework, that might be using it.

I instead would go with PHPUnit integration, as I said before.

@isimmons:

Ah, ok wasn't thinking about having all those functions in the global namespace. Was just used to other libraries I've been using that are psr-0 so I would do something like

use Hamcrest\MatcherAssert as h;

h::assertThat();

or my own helper files where I would load them in global

@aik099:

You still need to import every matcher class before using it :(

So you can basically warp a class around that Hamcrest.php and here import that file in your script :)

@adri:

You can now use:

use Hamcrest\MatchersAssert as h;
use Hamcrest\Matchers as m;

h::assertThat(array(), m::anArray());

[cordoval]

@aik099 i feel this can be closed, could you please confirm?

[aik099]

Agree. I believe, that moving to PHP namespaces solves global scope pollution problem completely.