Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:96578
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=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
In-Reply-To: <6954f170-bd74-310f-9ae2-23bda498603d@gmail.com>
Date: Mon, 24 Oct 2016 13:02:09 +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: <DD49677D-6268-4E6F-A42D-C6372EF2AB4E@koalephant.com>
References: <CABdc3WpeqPVfz=RgViAg55pXT_XdgWWWBngTReed31Tt1rwk1g@mail.gmail.com> <1e7da1db-9fc6-a3ce-9cba-b219af2dd7d4@gmail.com> <7F1CFE1E-48A4-450E-BFD5-645100A16AE9@koalephant.com> <6b490ba3-ad2d-2a2b-9117-de53ce7fea7f@gmail.com> <D7FD6A69-4CBE-4900-A61D-BC4E6CCC6E62@koalephant.com> <6954f170-bd74-310f-9ae2-23bda498603d@gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Object type hint
From: php-lists@koalephant.com (Stephen Reay)

Hi,

I didn=92t suggest we add anything because why not. Knowing something is =
an object is quite similar to knowing something is an array, and we have =
type hints for those. You don=92t know what the array holds exactly, but =
you know it=92s an array and that you can call array methods safely =
without type errors.

I honestly don=92t see the difference between the following (except that =
one is currently possible without extra is_* type checks):

foo(array $bar) {
	if (array_key_exists(=91something=92, $bar)) {=85}
}

foo(object $bar) {
	if (property_exists($bar, =91something=92) {=85}
}

So to carry on from that, how is the above not less boiler plate than:
=09
foo(object $bar) {
	if (!is_object($bar)) {
		throw new \InvalidArgumentException(=91foo expects =
parameter 1 to be an object, =91 . gettype($bar) . =91 given=92);
	}=09
	if (property_exists($bar, =91something=92) {=85}
}



Cheers

Stephen



> On 24 Oct 2016, at 12:48, Stanislav Malyshev <smalyshev@gmail.com> =
wrote:
>=20
> Hi!
>=20
>> Like I said, the functionality is possible without it. But what
>> functionality was impossible without int/float/string type hints?
>=20
> I don't think it's a good argument "if we added something to the
> language, from this point on anything can be added because why not?"
> Yes, you can write code in machine code, and yes, we don't do that, =
but
> that doesn't mean any addition to syntax anybody can think of
> automatically is in because we once added syntax.
>=20
>> They just make it much clearer, with less repeated boiler plate, what
>> arguments you can actually accept.
>=20
> I don't see how it's less boilerplate - in most cases, you don't even
> need it, as I said, since checking for object is in most cases is
> useless, you need to check for specific type. You don't use -> on just
> random object. You use it on an object because you expect to find
> something on the other end of -> and only objects of specific type(s)
> would have it.
>=20
> In very rare cases where it might may make sense, using is_object is
> only marginally longer and is very clear. It's not like it's some =
weird
> obscure function that takes ages to understand.
>=20
> --=20
> Stas Malyshev
> smalyshev@gmail.com
>=20