Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:96583
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain brzuchalski.com designates 188.165.245.118 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAEUnE0cA4EdaYZwAkejVtuVX0e8W+PtojnY36_Wfo9OhgSAA0Q@mail.gmail.com>
References: <CABdc3WpeqPVfz=RgViAg55pXT_XdgWWWBngTReed31Tt1rwk1g@mail.gmail.com>
 <CAEUnE0cA4EdaYZwAkejVtuVX0e8W+PtojnY36_Wfo9OhgSAA0Q@mail.gmail.com>
Date: Mon, 24 Oct 2016 09:21:24 +0200
Message-ID: <CABdc3WrJOmujcJBUK2b5cyKhFicf0_rbkeVWhRb58RvYtXCNyQ@mail.gmail.com>
To: Michael Morris <tendoaki@gmail.com>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=94eb2c0c09885726b9053f973db3
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Object type hint
From: michal@brzuchalski.com (=?UTF-8?Q?Micha=C5=82_Brzuchalski?=)

--94eb2c0c09885726b9053f973db3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2016-10-24 8:45 GMT+02:00 Michael Morris <tendoaki@gmail.com>:

> On Sun, Oct 23, 2016 at 3:39 AM, Micha=C5=82 Brzuchalski <
> michal@brzuchalski.com>
> wrote:
>
> > Hi all,
> >
> > I would like to initiate discussion for Object typehint RFC
> > https://wiki.php.net/rfc/object-typehint
> >
> > 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 u=
se
> > 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.
> >
> >
> Type hinting, along with the assert statement, provide a means to establi=
sh
> expectations for a methods. It's part of a coding paradigm known as 'desi=
gn
> by contract' and it's critical for large teams and projects that are used
> among multiple teams.
>

assert statement cannot be defined in method declaration, using typehiunt
does
Anything inside a method can do the same - that's right, but none of those
assert
and even is_object cannot be in method declaration, that's why it cannot be
inherited
by sub-classes and that is why `object` typehuiint is more powerfull
Additionally it more clear to read method declaration with static analysers
and detect abnormal usage simply by static analysis. It's impossible with
assertions!


>
> Checking to see if a variable is an object in no way provides a real test
> of what can be done with it.  Can it be iterated on? Probably, but not
> always. Does a method exist on the object? No way to know without further
> testing.
>
> Defining what an object can do is the reason interfaces exist. This is al=
so
> why objects are allowed to implement multiple interfaces, so that they ca=
n
> be labeled according to all the roles they can fulfill.
>

There are usage of object variables described in RFC which doesn't need any
behavior
from an object, they simply need variable to be object, and that's all,
thats the real world
use cases described in RFC.
Sorry but your argumentation doesn't convince me to not introduce described
feature.


> My principle worry with this RFC is it encourages an anti-pattern - not
> using interfaces and thereby not clearly labeling what objects can and
> cannot do.
>

There are examples of use cases. Speaking of pattern the DI pattern is
designed
to provide services, they doesn't need to implement any specific interface.
There was a question earlier what about services - they need to implement
specific behaviour - but that's not true, you do not expect in DI pattern
any service
need to implement anything, you simply expect only services, which do need
to be
objects, and that is all the case. You cannot type hint against Service,
Closure etc,
because you don't know in DI what kind of service it is and that's not the
point of DI
The real point of DI is to provide service whatever it is, and that's why
object type is for.


> The one situation this might be useful requires additional testing anyway=
 -
> that would be a method that will receive objects of one or more classes
> that don't have a common interface and rewriting the class to add the
> desired interface isn't viable (for example, the objects come from
> different packages). In that event though type hinting for an object is
> only going to be the first step in determining if the code state is sane,
> you'll also need to check if the object belongs to one of the several
> classes the code can work with.  This gets even hairier when dealing with=
 a
> collection of objects.  I wrote this generic assertion for Drupal 8.
>
> https://api.drupal.org/api/drupal/core%21lib%21Drupal%
> 21Component%21Assertion%21Inspector.php/function/Inspector%3A%
> 3AassertAllObjects/8.2.x
>

You're missing is_object on $member in foreach in your implementation
and it won't be even needed if there where object type hint.


> In your own code you'll likely need to do something similar with your
> argument.  Incidentally, these sorts of tests, which can only fail if the
> code is wrong, are what assert statements are to be used for, not
> exceptions. This way the check for correct objects can be turned off in
> production to avoid the cpu overhead of the test (assuming your function
> doesn't need to switch to different branches depending on the exact objec=
t
> used).
>
> In summary, -1 to this as it encourages bad code writing.
>



--=20
regards / pozdrawiam,
--
Micha=C5=82 Brzuchalski
about.me/brzuchal
brzuchalski.com

--94eb2c0c09885726b9053f973db3--