Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:96569
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain koalephant.com designates 206.123.115.54 as permitted sender)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
In-Reply-To: <1e7da1db-9fc6-a3ce-9cba-b219af2dd7d4@gmail.com>
Date: Mon, 24 Oct 2016 12:00:44 +0700
Cc: =?utf-8?Q?Micha=C5=82_Brzuchalski?= <michal@brzuchalski.com>,
 PHP Internals List <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <7F1CFE1E-48A4-450E-BFD5-645100A16AE9@koalephant.com>
References: <CABdc3WpeqPVfz=RgViAg55pXT_XdgWWWBngTReed31Tt1rwk1g@mail.gmail.com> <1e7da1db-9fc6-a3ce-9cba-b219af2dd7d4@gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Object type hint
From: php-lists@koalephant.com (Stephen Reay)

I can see uses for it, although none of them are impossible without the =
object typehint - they currently do an is_object() check.

In the same way that Iterable type hint allows you to safely do a =
foreach on an argument, object allows you to safely use property =
accessor syntax (i.e. ->). For me it would be most useful in lower level =
utility classes.


Cheers

Stephen

> On 24 Oct 2016, at 06:04, Stanislav Malyshev <smalyshev@gmail.com> =
wrote:
>=20
> Hi!
>=20
>> I would like to initiate discussion for Object typehint RFC
>> https://wiki.php.net/rfc/object-typehint
>=20
> I don't see why it would be important that the variable is an object =
but
> not important which kind of an object. There's very small number of
> things you can do with an object without knowing the exact type. For
> generic functions, like serialization, there's no reason why they
> shouldn't be able to serialize integers or nulls or booleans. On the
> contrary, many objects would not be serializable. For less generic
> functions, like DI containers, object type is next to useless since =
you
> can't just pass any object to implement a service - it should actually
> implement the required service. So adding "object" does not add real
> specificity to it.
>=20
>> 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.
>>=20
>> 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.
>=20
> They probably think more "strictness" and more checks means better =
code.
> It is usually not true per se. E.g. in the RFC examples the type does
> not seem to be serving a good purpose - it's either wrong (like in the
> case of json_decode - it won't always return an object), or =
nonspecific
> - like in factory, very rarely one has a factory returning just
> arbitrary objects, no matter what they are.
> --=20
> Stas Malyshev
> smalyshev@gmail.com
>=20
> --=20
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>=20