This is only for cases when libphutil is used in a separate project that doesn't have autoloaders registered.
PHP does not seem to care if class_exists() is called with no autoloaders registered. So if the phutil autoloader is the only one and I do class_exists('my_custom_class') then __phutil_autoload will throw.
Maybe no fix is needed and it is just a documentation issue.
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Resolved | epriestley | T1116 Function __phutil_autoload should probably not throw an exception if it is the only registered autoload function | ||
| Restricted Maniphest Task | ||||
| Restricted Maniphest Task |
Yeah, I'll get this documented. Two workarounds:
If neither of these are reasonable I'd be okay with introducing a "don't throw on missing classes" flag somewhere too, they've just been reasonable in all the cases we've run into so far.
We could also do a debug_backtrace() and check if we're inside a class_exists() or interface_exists() and not throw. And we could just not throw and let PHP handle the failure appropriately, but that would produce a much less useful message in the common case where you typed "new ClassThatDoesNotExist".
Cool. I did the second suggestion and just registered an empty function, solved the issue. (I'm using codeigniter and they use class_exists pretty extensively and I didn't want to change it)
Some related discussion here:
https://secure.phabricator.com/chatlog/channel/%23phabricator/?at=17878
Providing a separate include point for external libraries to use probably makes a good deal of sense.
The progress in T1103 makes using libphutil in external libraries generally more reasonable too, since we no longer need phutil_require_module() to get functions defined.
D14523 possibly describes a cleaner fix for this (special case autoloads when class_exists() is on the stack).