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.
> 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?
> 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.
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".
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
