I think you are confusing a few things. We don’t work for Zend Technologies Ltd. At least most of us. We are just contributors and some are maintainers, doing this all in our spare time. Zend Technologies Ltd sponsors this Zend Framework in some ways but I don’t know the details of that.
We don’t introduce this, it’s in PHPUnit and has been in there for ages.
If you don’t like things in PHP, you have to go to php.net or php-src on GitHub as they are responsible for that.
I’m not sure what you mean by pre-Zend times. AFAIK PHP uses the Zend Engine since version 4. So that would mean you liked PHP 3 and after that, it went downwards?
Anyway, we are derailing here. The reason I started this topic was to ask what we should use when submitting PR’s.
Name Zend Framework strongly suggests that this is sponsored by Zend. Meaning they have the right for key decisions here, like what the shape of ZF will be.
And hell yes:: PHP3 is what I really liked. It wasnt modern (for todays standards), but it was stable = without any zend* things packed everywhere
Its not my fault that Zends represtatives hired unskilled developers who produces crap. Yes - with each PHP release (starting from 4), each new version is more crappy than previous.
Name Zend Framework strongly suggests that this is sponsored by Zend.
Meaning they have the right for key decisions here, like what the shape of
ZF will be.
False: the ZF community has always had the last word in basically every
larger BC break or new feature.
Zend is sponsoring Enrico’s and Matthew’s work, but that doesn’t come with
control over what lands in the repositories, as we all (ZF community) keep
an eye on it.
The discussion in this thread is an example of it: I am a proponent of the self:: approach, and others are not, and it is open for decision to go
either with $this-> or self::.
And hell yes:: PHP3 is what I really liked. It wasnt modern (for todays
standards), but it was stable = without any zend* things packed everywhere
If you liked PHP3, you can still deploy PHP3: why are you even involved in
a discussion on a board that talks about a “modern” set of libraries?
Its not my fault that Zends represtatives hired unskilled developers who
produces crap. Yes - with each PHP release (starting from 4), each new
version is more crappy than previous.
I suggest you wash your eyes (and mouth): try writing something stable,
fast, secure and matching business requirements with PHP3 nowadays, and
good luck with passing any pentesting or peer review.
Also, I’m fairly sure that you confuse ZendFramework (Community project)
with the Zend Engine (implementation detail of PHP core), and that you have
little to no clue of what you are referring to.
I know that - with stagnated PHP v3. it would be close to impossible, but what I meant was if Zend was serious, they would either allow community to work on PHP (4 or whatever name/version) and have it shaped as community likes/wants, or, take over development, close source code and pack it with all these unnecesary (and unfinished) crap, because what really matters is money (they actually have chosen second path (in fact they mixed and modified both ways) …
If PHP (core) was developed by community (for fun), not by company (for money), PHP would be totally different (= better) today. Thats my point.
Generally talking (not only of Zend, but of OSS as a whole):: I strongly think that creating company to support OSS development is great misunderstanding of what OSS really is. Once you start company to back your dev need, you stop developing free (=OSS) software, as company = influence. Many good (very good) project that started as OSS were driven towards their end this way. Sad, really sad.
If so, than why is there word Zend in the name of the framework? Also, whats BC?
try writing something stable,fast, secure and matching business
requirements with PHP3 nowadays
I know that - with stagnated PHP v3. it would be close to impossible,
but what I meant was if Zend was serious, they would either allow community
to work on PHP (4 or whatever name/version) and have it shaped as community likes/wants, or, take over development, close source code
and pack it with all these unnecesary (and unfinished) crap, because
what really matters is money (they actually have chosen second path (in
fact they mixed and modified both ways) …
If PHP (core) was developed by community (for fun), not by company (for
money), PHP would be totally different (= better) today. Thats my point.
PHP (language) is developed by the community. Some maintenance work is
sponsored by companies, but decision-making is wide open and available to
everyone in PHP: rfc
Generally talking (not only of Zend, but of OSS as a whole):: I strongly
think that creating company to support OSS development is great
misunderstanding of what OSS really is. Once you start company to back your
dev need, you stop developing free (=OSS) software, as company = influence.
Many good (very good) project that started as OSS were driven towards their
end this way. Sad, really sad.
I think you misunderstand how OSS works, plus you come here to complain
about work done for free and for everyone.
Your next OT post on this thread will likely grant you a kick out of this
discourse.
oh yes, run out of arguments and start threatening… well known scenario…
As name says its discussion board created for discussing things. Fact that you dont want/are unable to admit (due to CA or other shit) that Zend should have never been born, doesnt give you (or anyone else) right to act the way you act.
Im free to express my point(s) of view freely as long as Im not offending anyone; and Im not ding this here (=on this forum). So I dont understand why is that you are threatening me with ban. We have freedom of speech.
PHPUnit’s assertions are implemented in PHPUnit\Framework\Assert. PHPUnit\Framework\TestCase inherits from PHPUnit\Framework\Assert.
The assertion methods are declared static and can be invoked from any context using PHPUnit\Framework\Assert::assertTrue(), for instance, or using $this->assertTrue() or self::assertTrue(), for instance, in a class that extends PHPUnit\Framework\TestCase.
In fact, you can even use global function wrappers such as assertTrue() in any context (including classes that extend PHPUnit\Framework\TestCase) when you (manually) include the src/Framework/Assert/Functions.php sourcecode file that comes with PHPUnit.
A common question, especially from developers new to PHPUnit, is whether using $this->assertTrue() or self::assertTrue(), for instance, is “the right way” to invoke an assertion. The short answer is: there is no right way. And there is no wrong way, either. It is a matter of personal preference.
For most people it just “feels right” to use $this->assertTrue() because the test method is invoked on a test object. The fact that the assertion methods are declared static allows for (re)using them outside the scope of a test object. Lastly, the global function wrappers allow developers to type less characters (assertTrue() instead of $this->assertTrue() or self::assertTrue()).
(from phpunit docs)
All three methods are fine. $this->assert(, self::assert( and assert(. I just feel since it’s interface is declared as static why not use it that way until there is a need not to do so?
My only objections are the resulting inconsistencies and the time it requires to cleanup (see above $this->assert* vs self::assert* - I’m afraid it got lost due to the off-topic discussions). Otherwise I don’t care
Regarding your points, this one is the one I’m struggling to think of a good enough solution for…
As for existing tests, it would be a lofty task indeed but that doesnt make it not worth doing imo, should the decision to do it be taken, and I suspect a certain amount of automation/tooling would assist.
