Hi Michal!
First of all, many thanks to you and Dan for pushing this forward. It is
indeed a very needed and long due addition to the engine.
I just wanted to clear up the use-case scenarios for everyone in here that
keeps stating that this will lead to bad code.
It is very unlikely to type-hint "object" inside your business domain.
Where this functionality is useful is any of the following (with examples):
- generic hydrators/property access (these exist, and they are widely used
inside form components)
class SillyLibraryHidrator
{
public function hydrate(object $object, array $someData)
{
// pseudo:
foreach ($objectReflectionProperties as $p) {
$p->setValue($object, $someData[$p->getName()]);
}
}
}
- serializers - also widely used, can generally tell them to produce an
object of a certain type. Consumers would then wrap it, and use a more
specific type-hint
interface JsonSerializer
{
public function serialize(object $object) : string;
public function deSerialize(string $data, string $className) : object;
}
- identity maps - typically part of ORMs
interface IdentityMap
{
public function add(string $id, object $object) : void;
public function getId(object $object) : ?string;
public function getObject(string $id) : ?object;
}
- code generators
interface WrapThingIntoAProxy
{
public function wrap(object $object) : object;
}
- instantiation logic for generic factories
interface AGenericFactory
{
public function create(array $data, string $className) : object;
}
- table data gateways/repositories
interface TableDataGateway
{
public function fetchById(array $identifier) : ?object;
}
These are just some of the examples that get direct benefit from this sort
of type-hint, or at least the scenarios that I work with on a daily basis.
Please don't tell me that I have to get back to `is_object()`, because:
* it is implicitly part of the implementation, and not part of the
reflectable signature *AS IT SHOULD BE*
* it is more code for me to test
* I cannot throw a TypeError myself, if a non-object is given (TypeError
can't be instantiated in userland, AFAIK), and every time I have to design
custom exceptions (also to be tested/documented)
* this way is actually faster than a manual `is_object()` check
* intent is conveyed to the consumer directly, and not via documentation
docblock
* allows for explicit nullability, yet splitting object/non-object APIs
* many library-level codebases rely on generic code that doesn't know
about one specific type, but just about "objects"
The alternative is going with full generics, but that's not viable for now.
This additional type hint is pretty much covering the scenarios above in a
very approachable way.
Greets,
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
On Sun, Oct 23, 2016 at 12:39 AM, Michał Brzuchalski <mic...@brzuchalski.com
> wrote:
> Hi all,
>
> I would like to initiate discussion for Object typehint RFC
> https://wiki.php.net/rfc/object-typehint
>
> This feature is developed to provide missing functionality which is needed
> and quite easy to introduce.
> There are many people which I've talked about the benefits of this
> functionality.
>
> For those who doesn't like the idea and think they won't need neither use
> it rather than just saying 'no' they
> please say why other people who want to use that parameter type are wrong,
> for wanting to do that.
>
> If there is anything left to discuss, please comment.
>
> Thanks to @Danack for drafting.
> --
> regards / pozdrawiam,
> --
> Michał Brzuchalski
> about.me/brzuchal
> brzuchalski.com
>
