-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
___ #8573
Comments
@ecreeth Could you explain your rationale for #3874? Is this okay to close because this behavior is also correct, but just different from PHP? Or are we merely closing this because of the PHP comparison? (new ReflectionFunction($closure))->isClosure(); The issue says that this returns false. Does it still do that today? That seems like something worth fixing. |
@lexidor This is due to the comparison with php and the year it was created |
The quirks that were mentioned in the issue are still accurate to this day. The example does not work out of the box, since HHVM + Hack 4.38.0-dev (rel)
PHP + php 7.4.1 (cli)
I don't speak Reflectionista and I don't know if anyone uses this / cares. <?hh // partial
//<?php
function main(): void {
$ship = new Ship();
$rf = new ReflectionFunction($ship->getClosure());
$rf = $rf->getParameters()[0]->getDeclaringFunction();
\var_dump($rf->isClosure());
\var_dump($rf->getClosureScopeClass());
\var_dump($rf->getDeclaringClass());
}
class Ship {
public function getClosure() {
return function(string $canon_to_fire) {
return false;
};
}
}
main(); P.S. This doesn't need to be a PHP closure to have his behavior. I used one because of the |
I am going over old issues on this repository, to see which ones apply to the current versions of hhvm. We've come full circle. To all those issues that are on the list above, that I have not closed: I mainly focused on closing issues that relied on features that were removed from hhvm or relied on php mode. I am updating the issue title of this issue to three underscores in order to not swing the discussion on whether to keep your issue open. |
The following issues are stale and keeping the issue count on hhvm high:
ArrayAccess<_, _>
anyhow since hack will tell you that you are using a subscript operator on something that is not aKeyedContainer<_, _>
$foo = new Foo(); $foo['a'] = 'b';``Typing[4005] This is not an object of type KeyedContainer, this is an object of exactly the class Foo
.@fredemmott
was trying to do what hhvm-autoload is doing now. I presume that hhvm is providing the required functions and hooks to perform this, else how would hhvm-autoload do it?hhvm -m server
and vardumping the keys of$_SERVER
..json
files just fine. That might be because of how my op configured it though. It doesn't seem like this is an issue anymore.($this->callable_property)(...$args)
require_once
(likeecho
and friends) is an untyped statement. This is expected behavior. You should not be requiring things yourself if you can help it. Autoloading is baked into the core of hhvm. The only thing that really needs to be required these days is/vendor/bin/autoload.hack
.call_user_func_array
takesContainer<_>
, stdClass is stopped at typecheck time.// strict
.Okay, this took waaay to long already. Will flag a couple of issues every time I create a new one. I want the issue count to slowly go down to something that is more manageable.
The text was updated successfully, but these errors were encountered: