Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:96586
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.43 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CABdc3WpeqPVfz=RgViAg55pXT_XdgWWWBngTReed31Tt1rwk1g@mail.gmail.com>
References: <CABdc3WpeqPVfz=RgViAg55pXT_XdgWWWBngTReed31Tt1rwk1g@mail.gmail.com>
Date: Mon, 24 Oct 2016 01:26:50 -0700
Message-ID: <CADyq6sJBGB2F0twhDMV1-xWzvaOwL-Rg2mr=3L7J+UizR2qX5Q@mail.gmail.com>
To: =?UTF-8?Q?Micha=C5=82_Brzuchalski?= <michal@brzuchalski.com>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a114426fc899368053f9828a9
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Object type hint
From: ocramius@gmail.com (Marco Pivetta)

--001a114426fc899368053f9828a9
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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=C5=82 Brzuchalski <michal@brzuchals=
ki.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 neede=
d
> 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=C5=82 Brzuchalski
> about.me/brzuchal
> brzuchalski.com
>

--001a114426fc899368053f9828a9--