Open Ocramius opened 11 years ago
I'll classify it as "Unintended but working as expected" behavior.
My original parser simply include-ed the class into memory and then used reflection to determine if it was a child of AthleticEvent. But this had problems when running more than one test at a time (e.g. class was already loaded).
So I rewrote it with a simple PHP parser, which is limited to classes that directly extend AthleticEvent
(because there is no reflection, so it has to rely on the PHP tokens itself).
What's your use-case? I'll have to play around with a way to allow "grand-children". I can dig around PHPUnit's code too...assuming they let you do similar extended inheritance?
@polyfractal looking into PHPUnit is a good idea indeed. For now I simply renamed all my classes, so I wouldn't bother with this...
Cool. I'll definitely look into a better parser. This was one of those "afternoon in an hour" pieces of code :)
Same issue, my use case: PHP 5.3 environment where I cannot use traits, but need some common behavior amongst all my events. Thus I want:
class MyBaseEvent extends Athletic\AthleticEvent { // <--- do not try to run this
protected function somethingCommon() { }
}
class ActualEvent extends MyBaseEvent { // <--- run this
public function clock_something() {
$this->somethingCommon();
}
}
The current implementation of
Athletic\Discovery\Parser
does not allow discovered events to inherit from classes that do not containAthleticEvent
in their name.I'm not sure why this limitation is in place, but the parser looks quite simplistic, and honestly I don't have a quickfix for it right now.
The idea is to use a more sophisticated parser, but that would of course mean having a much heavier logic.
Is this intended or bogus behaviour?