Hi,
I didn’t 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’t know what the array holds exactly, but you know it’s
an array and that you can call array methods safely without type errors.
I honestly don’t see the difference between the following (except that one is
currently possible without extra is_* type checks):
foo(array $bar) {
if (array_key_exists(‘something’, $bar)) {…}
}
foo(object $bar) {
if (property_exists($bar, ‘something’) {…}
}
So to carry on from that, how is the above not less boiler plate than:
foo(object $bar) {
if (!is_object($bar)) {
throw new \InvalidArgumentException(‘foo expects parameter 1 to
be an object, ‘ . gettype($bar) . ‘ given’);
}
if (property_exists($bar, ‘something’) {…}
}
Cheers
Stephen
> On 24 Oct 2016, at 12:48, Stanislav Malyshev <smalys...@gmail.com> wrote:
>
> Hi!
>
>> Like I said, the functionality is possible without it. But what
>> functionality was impossible without int/float/string type hints?
>
> 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.
>
>> They just make it much clearer, with less repeated boiler plate, what
>> arguments you can actually accept.
>
> 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.
>
> 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.
>
> --
> Stas Malyshev
> smalys...@gmail.com
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
