hack-psr / psr7-http-message-hhi
Typechecker definitions for PSR-7
Installs: 471 034
Dependents: 6
Suggesters: 0
Security: 0
Stars: 7
Watchers: 6
Forks: 2
Open Issues: 0
Language:Hack
Requires
- psr/http-message: ^1.0
This package is auto-updated.
Last update: 2024-10-13 10:46:58 UTC
README
This repository contains .hhi files for the interfaces defined in PSR-7. It is based on the PHP interface definitions and comments available here:
https://github.com/php-fig/http-message
HHI files are ignored by HHVM, however they give the typechecker information about the interfaces. This allows usage of the canonical PHP interface at runtime, while also giving the benefits of static type checking.
Installation
composer require hack-psr/psr7-http-message-hhi
Notes
RequestInterface::getRequestTarget()
is marked as@return string
, however this is not always accurate, given thatRequestInterface::withRequestTarget()
explicitly allows any type for the request target, which must be preserved verbatim - https://github.com/php-fig/http-message/issues/67ServerRequestInterface::getParsedBody()
is specified as returningnull|array|object
so is typed here asmixed
. There has been some discussion about banning theobject
case as any usage couples you to a specific implementation or stack, which would allow it to be typed as?array<string,mixed>
. This is not done because PHP implementations would not have to honor this type.ServerRequestInterface::getQueryParams()
andgetUploadedFiles()
return untyped arrays as they return a tree-like structure instead of a key-value structure - eg?a[b][c]=123
. They could be typed asarray<string,mixed>
, however this would make them much more inconvenient to use.- The return value of these functions is not defined in PSR7; this project
defines them as returning
void
to prevent users depending on unspecified behavior (https://github.com/php-fig/http-message/issues/68):StreamInterface::seek()
StreamInterface::rewind()
UploadedFileInterface::moveTo()
- The combination of these means that the most user-friendly (and safe) hack definition of this interface isn't suitable for use by implementations (see #2)
Future Work
Create a derived standard for Hack, addressing the above notes. Ideas include:
- banning non-string request targets
- banning
object
parsed bodies - flattening
getUploadedFiles
,getParsedBody
,getQueryParams
This would be a separate project.