hhvm-nightly (and next week's release) now report 4.x, so all the 3.x
constraints are now giving misleading error messages with this patch.
Before:
```
- facebook/fbexpect v2.3.0 requires hhvm ^3.28 -> you are running this with PHP and not HHVM.
```
After:
```
- facebook/fbexpect v2.3.0 requires hhvm ^3.28 -> your HHVM version (4.0.0-dev) does not satisfy that requirement.
```
According to type 2nd constructor-argument `$reasonData` can either be a Link or a PackageInterface. IDEs like PhpStorm won't be able to provide autocompletion since both classes are from a different namespace.
In order to provide better autocompletion for `$reasonData` and by extension `$this->reasonData` the use statements should be included or the type hint should use the fully qualified class name.
For the same reason I added the docblock on the protected method `formatePackagesUnique()`.
It is known that composer update takes a lot of memory: #5915, #5902,
I am playing with a profiler (@blackfireio) to make a demo in my local
PHP meetup (@phpvigo) and I found out a way to use less memory. These
are my first tests:
* Private project using PHP 5.6:
* Memory: from 1.31GB to 1.07GB
* Wall Time: from 2min 8s to 1min 33s
* symfony-demo using PHP 7.1 in my old mac book:
* Memory: from 667MB to 523MB
* Wall Time: from 5min 29s to 5min 28s
Not use an array inside conflict rules is this improvement main idea:
```php
<?php
//Memory 38MB
gc_collect_cycles();
gc_disable();
class Rule
{
public $literals;
public function __construct(array $literals)
{
$this->literals = $literals;
}
}
$rules = array();
$i = 0;
while ($i<80000){ //
$i++;
$array = array(-$i, $i);
$rule = new Rule($array);
$rules[] = $rule;
}
```
```php
<?php
//Memory 11.1MB
gc_collect_cycles();
gc_disable();
class Rule2Literals
{
public $literal1;
public $literal2;
public function __construct($literal1, $literal2)
{
$this->literal1 = $literal1;
$this->literal2 = $literal2;
}
}
$rules = array();
$i = 0;
while ($i<80000){ //
$i++;
$rule = new ConflictRule(-$i, $i);
$rules[] = $rule;
}
```
More info https://github.com/composer/composer/pull/6168
The hash is necessary as comparisons are significantly too slow
otherwise. The old hash function used substr on the hexadecimal
representation of the md5 hash, rather than the raw binary output. This
wastes a significant amount of memory, as each byte can only be used to
store up to 4 bit of information. The new hash has 32bit instead of
20bit and uses only a 4 byte integer instead of a 5 byte string.
Since we no longer have suggest/recommend rules and no longer use any update
or feature rules so packages are removed by default, we do not need weak rules
anymore.
As it is faster to remove packages from the repos and keep them out of the
package pool to begin with, we don't need an installable() method on the
policy.
Fred Emmott