zendframework/zend-stdlib
Zend\Stdlib provides general-purpose utility components for PHP, including array helpers, messaging utilities, string wrappers, and more. Note: this repository was abandoned on 2019-12-31 and moved to laminas/laminas-stdlib.
$content property
of the Message class to indicate it is a string. All known implementations
already assumed this.Zend\Stdlib\ConsoleHelper class, providing minimal support for writing
output to STDOUT and STDERR, with optional colorization, when the console
supports that feature.Zend\Stdlib\JsonSerializable, as all supported version of PHP now support
it.Zend\Json\Json::GLOB_BRACE constant on systems using
non-gcc glob implementations.Zend\Stdlib\CallbackHandler see #35Zend\Stdlib\DateTime; this had been deprecated since 2.5, and only
existed as a polyfill for the createFromISO8601() support, now standard
in all PHP versions we support.Zend\Stdlib\Exception\InvalidCallbackException, which was unused since #33.Zend\Stdlib\Guard\GuardUtils, which duplicated Zend\Stdlib\Guard\AllGuardsTrait
to allow usage with pre-PHP 5.4 versions.src/compatibility/autoload.php, which has been dprecated since 2.5.Zend\Stdlib\CallbackHandler, as the one component that used it,
zend-eventmanager, will no longer depend on it starting in v3.FastPriorityQueue::remove() logic that occurs when removing
items iteratively from the same priority of a queue.HydratorInterface to also extend the zend-hydrator HydratorInterface to
ensure LSP is preserved.FastPriorityQueue to alias SplPriorityQueue in order to disambiguate with
the local override present in the component.#19 adds a new
FastPriorityQueue implementation. It follows the same signature as
SplPriorityQueue, but uses a performance-optimized algorithm:
SplPriorityQueue and 3x faster than the
Zend\Stdlib\PriorityQueue implementation.SplPriorityQueue and 4-5x faster than the
Zend\Stdlib\PriorityQueue implementation.The intention is to use this as a drop-in replacement in the
zend-eventmanager component to provide performance benefits.
#20 deprecates all
hydrator classes, in favor of the new zend-hydrator
component. All classes were updated to extend their zend-hydrator equivalents,
and marked as [@deprecated](https://github.com/deprecated), indicating the equivalent class from the other
repository.
Users should immediately start changing their code to use the zend-hydrator
equivalents; in most cases, this can be as easy as removing the Stdlib
namespace from import statements or hydrator configuration. Hydrators will be
removed entirely from zend-stdlib in v3.0, and all future updates to hydrators
will occur in the zend-hydrator library.
Changes with backwards compatibility implications:
Users implementing Zend\Stdlib\Hydrator\HydratorAwareInterface will need to
update their setHydrator() implementation to typehint on
Zend\Hydrator\HydratorInterface. This can be done by changing the import
statement for that interface as follows:
// Replace this:
use Zend\Stdlib\Hydrator\HydratorInterface;
// with this:
use Zend\Hydrator\HydratorInterface;
If you are not using imports, change the typehint within the signature itself:
// Replace this:
public function setHydrator(\Zend\Stdlib\Hydrator\HydratorInterface $hydrator)
// with this:
public function setHydrator(\Zend\Hydrator\HydratorInterface $hydrator)
If you are using Zend\Stdlib\Hydrator\HydratorAwareTrait, no changes are
necessary, unless you override that method.
If you were catching hydrator-generated exceptions, these were previously in
the Zend\Stdlib\Exception namespace. You will need to update your code to
catch exceptions in the Zend\Hydrator\Exception namespace.
Users who do migrate to zend-hydrator may end up in a situation where their code will not work with existing libraries that are still type-hinting on the zend-stdlib interfaces. We will be attempting to address that ASAP, but the deprecation within zend-stdlib is necessary as a first step.
In the meantime, you can write hydrators targeting zend-stdlib still in order to guarantee compatibility.
Zend\Stdlib\Hydrator\Iterator, which provides mechanisms for hydrating
objects when iterating a traversable. This allows creating generic collection
resultsets; the original idea was pulled from
PhlyMongo, where it was used to hydrate
collections retrieved from MongoDB.How can I help you explore Laravel packages today?