Page MenuHomePhabricator

Add "phutil_describe_type()" and clean up a few obscure things in "libphutil/"
ClosedPublic

Authored by epriestley on Feb 26 2019, 3:13 AM.
Tags
None
Referenced Files
Unknown Object (File)
Feb 7 2024, 10:39 PM
Unknown Object (File)
Jan 6 2024, 4:48 AM
Unknown Object (File)
Dec 27 2023, 1:30 PM
Unknown Object (File)
Dec 24 2023, 10:46 PM
Unknown Object (File)
Dec 22 2023, 10:52 PM
Unknown Object (File)
Dec 21 2023, 12:11 PM
Unknown Object (File)
Nov 30 2023, 5:54 AM
Unknown Object (File)
Nov 30 2023, 12:25 AM
Subscribers
None

Details

Summary

See PHI1096. With some frequency, I want to raise an exception like "expected method getSomething() to return an object of type X, but it actually returned a thing of type Y".

There's no great builtin function for producing a good value for "Y", the unexpected value's type. "get_type()" is somewhat close, but just returns "object" for objects, when we'd prefer to return the object's class name since this is significantly more useful.

We have a pretty good method for producing "Y" in "libphutil/", but it's hard to remember: PhutilTypeSpec::getTypeOf($value). Wrap it in a convenient name, phutil_describe_type().

Also, provide phutil_is_natural_list() for simplifying the array_keys(...) === range(...) test that we have in a handful of cases.

Finally, clean up a couple of error behaviors that give you a bad/misleading error if you make a syntax error in "utils.php" specifically.

Test Plan

Ran unit tests, see also next diff.

Diff Detail

Repository
rPHU libphutil
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

amckinley added inline comments.
src/utils/utils.php
1769

Unfinished thought.

This revision is now accepted and ready to land.Feb 26 2019, 3:34 PM
  • One more similar language tweak.
This revision was automatically updated to reflect the committed changes.
src/conduit/ConduitClient.php
351

This accidentally fixed a bug, since PHP is a lovable trickster:

$ php -r 'echo (array("x") == array(0)) ? "SAME ARRAY" : "DIFFERENT";'
SAME ARRAY

That is, this should have been ===.

This bug isn't a huge issue, but it does change the signature algorithm.

This [signature] bug isn't a huge issue

Specifically, I mean it isn't a huge issue since we only use it internally today. If this was in widespread use it could be a real problem, since it would mean the signature algorithm doesn't protect against a MITM attacker very well, but you'd have to be inside the hosted cluster to do anything MITM-flavored today.