Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:96566
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.169 as permitted sender)
To: =?UTF-8?Q?Micha=c5=82_Brzuchalski?= <michal@brzuchalski.com>,
 PHP Internals List <internals@lists.php.net>
References: <CABdc3WpeqPVfz=RgViAg55pXT_XdgWWWBngTReed31Tt1rwk1g@mail.gmail.com>
Message-ID: <1e7da1db-9fc6-a3ce-9cba-b219af2dd7d4@gmail.com>
Date: Sun, 23 Oct 2016 16:04:12 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0)
 Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <CABdc3WpeqPVfz=RgViAg55pXT_XdgWWWBngTReed31Tt1rwk1g@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Object type hint
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> I would like to initiate discussion for Object typehint RFC
> https://wiki.php.net/rfc/object-typehint

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.

> 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.
> 
> 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.

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.
-- 
Stas Malyshev
smalyshev@gmail.com