hamcrest / hamcrest-php

PHP Hamcrest implementation [Official]
Other
6.95k stars 44 forks source link

Proper autoloading instead of require_once #15

Closed schickling closed 10 years ago

schickling commented 10 years ago

I think it's kinda "developer unfriendly" that you have to require_once the hamcrest files in order to use this plugin. This should already be done via composer.

As a quick and dirty solution I added this to my composer.json:

"include-path": ["Hamcrest-1.1.0/"]
aik099 commented 10 years ago

Unfriendly is to pollute the global scope, as was done originally in the library.

We've properly changed code to use namespaces, so what you actually need is to add use Hamcrest as h; to a PHP file and use h::... methods instead of using globally defined functions. For example h::anything() should work.

schickling commented 10 years ago

Thanks for your reponse @aik099

Well this makes also sense to me, but usually I use Hamcrest just in my dev dependencies, so the "pollution" is intended (in tests).

Is there a workaround to map the namespace for Hamcrest to the current one?

aik099 commented 10 years ago

Ups, that exact syntax isn't supported and you need to use long hamcrest classes directly.

@cordoval , it seems, that we forgot to wrap Hamcrest/Hamcrest.php into a static class within Hamcrest namespace as we planned initially. Without it developers need to know long matcher class names instead using shorthand functions.

aik099 commented 10 years ago

Is there a workaround to map the namespace for Hamcrest to the current one?

What you mean by namespace mapping?

schickling commented 10 years ago

What you mean by namespace mapping?

A simple way to "enable the pollution" without having to write h::asserThat(); every time.

aik099 commented 10 years ago

There is a simple way as you said: just add require_once to Hamcrest.php in you test suite bootstrap file. And you'll have your anything() and other functions back.

michael-donat commented 10 years ago

@aik099

You simply need:

use Hamcrest\Matchers as hm;
use Hamcrest\MatcherAssert as ha;

And then in test method

ha::assertThat(false, ha::is(false))

This will allow you to use short names without polluting main namespace.

That functionality is already built in and requires no changes.

Forgot your own code, have ya ;)?

schickling commented 10 years ago

Alright, I ended up adding "require_once" to my tests. Thanks a lot!

davedevelopment commented 10 years ago

It would be nice to get another level of proxying in, so that we can have the functions under a namespace, which will be great once 5.6 hits:


use function Hamcrest\assertThat, Hamcrest\endsWith;

assertThat("dave", endsWith("ve"));

It's just a pain to maintain. I do this with davedevelopment/dspec, were I essentially have:


namespace {
    function it() {
        call_user_func_array("DSpec\it", func_get_args());
    }
}

namespace DSpec {
    function it() {
        call_user_func_array("DSpec\DSpec::it", func_get_args());
    }

    class DSpec {
        static function it() { }
    }
}
aik099 commented 10 years ago

It's no pain to maintain, since we have a generator script that scans possible mather classes and generates methods for them in single Hamcrest.php file.