> On 24 Oct 2016, at 13:12, Stanislav Malyshev <smalys...@gmail.com> wrote:
> 
> 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
> 
> That's the point - it's not. Array is just an array, all arrays are the
> same inside. Objects are all different, SPLFileInfo object has nothing
> in common with PDORow object and with GMP number object.

The internals are irrelevant if you just want to check/read a public property.

> 
>> 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’) {…} }
> 
> I'm not sure how adding "object" helps here - now instead of checking
> when you call property_exists you need to check when you call foo().
> Same is achieved with is_object, and virtually in the same space. And
> also, why would you just check for properties of random object? What's
> the point of checking if GMP number has property "zyx" and the same for
> SPLFileInfo, in one function?

If you know (e.g. because of type hints, return types, or even object creation) 
that you have an object when you call foo(), no, you don’t. 
Thats the whole point of type hints, surely: to remove the need to have manual 
is_* calls all over your code.

> 
>> 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’)
>> {…} }
> 
> You can invent even longer code to show how hard it's to use php
> functions. I don't think it would make it very convincing. Adding
> language construct for it is like adding language construct for "throw
> exception if this variable equals to 0". Surely, it may be useful in
> some cases, but in most cases it's not adding anything and just adds
> clutter to the language and to the code.

It really isn’t, simple equals tests don’t require any boilerplate to be type 
safe. Or perhaps you’d argue that `===` is unnecessary because you can just do 
`is_int($foo) && $foo == 2` instead of `$foo === 2`?



> I understand there's a fashion that says if you have types on your
> variables that's always better, but I don't subscribe to this,
> especially when types are as generic as "object”.

Your voting history on type-related RFC’s makes your opinion on anything 
related to user-land types pretty clear. I’m now done debating this with you - 
you’re clearly going to vote no again regardless of what anyone says, so I’ll 
bid you a good day.



> -- 
> Stas Malyshev
> smalys...@gmail.com
> 


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to