Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:96581 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 22780 invoked from network); 24 Oct 2016 06:45:26 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 24 Oct 2016 06:45:26 -0000 Authentication-Results: pb1.pair.com smtp.mail=tendoaki@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=tendoaki@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.175 as permitted sender) X-PHP-List-Original-Sender: tendoaki@gmail.com X-Host-Fingerprint: 209.85.217.175 mail-ua0-f175.google.com Received: from [209.85.217.175] ([209.85.217.175:33245] helo=mail-ua0-f175.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 39/B8-28528-10EAD085 for ; Mon, 24 Oct 2016 02:45:23 -0400 Received: by mail-ua0-f175.google.com with SMTP id 6so8798298uat.0 for ; Sun, 23 Oct 2016 23:45:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=PbPBKaf4/YAlI+TB4Gxv1CLkDe5PjCuHdeAN8oZdBBY=; b=rlaI4bsdW2sIfVt0ti4l/3PU5wAUYdmUhHLKBNApSC/F9iLQ8/znYVGlw4jgpshpFc xPOMDTfYaxnkGLOkeJCCOqkvfZQ5POiCzBNCf77x6epzOmHFOEZjAtblr5KFqkztnHeN /pBOtMUfcWhSf/Yhlkdmbi0RYCVUEHCxn2c1bs47j1GH3hlm0sXJmKYMUIgUYP1Sht9y Krf9H6zL/7xHihlLVEM8ltWzfCBAC6PWnUCIhvxAwji7t8qoeGQO0qpdclY6pPlhyeiY uuknsLCLv5eXnmw8mEFuDx1xfC/BlKeC51UMimOZcDiq/Md5YUJ/EAoTwfPyj/SdSTJu l/eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=PbPBKaf4/YAlI+TB4Gxv1CLkDe5PjCuHdeAN8oZdBBY=; b=lu91VYdoM3lRnrg+YncryQsPhxMYtE9hWi8Q1fDBKI9WNKl24nhCLx2sjszOmU1JxV PSvIMk9yy5kW4dTgK9BIVs8MH6mr3zY0FXRZM3pM692/jtqNRoL9AtQHBckkcTZpaQ08 vA0Cs7570LYKMHxObavVuM7sU10I7d23GeihaobiOa2tq/H7e4R7JHjBOOuMPb8jpQac qcmL66S2Y9ZUYr+AkuqDG6ICXwNUT2XyGTwSxKx9PtlyPaFkUDcRPsNUmOjT7Lga8FkA CQ4qCu/qIfpzIX40E0Z/ie/MAIxOovtZ9Qg4e+5qMrHxEzULYmYZyVa3RS+nHuOIVM2D TO3A== X-Gm-Message-State: ABUngveVPR2GoXpRJ4NrpQ2gH6s2xw0//+253yIn6u5+l3oTAl3J+B7s00YD6+Z3Cm7x0boXFBnA/jE2E3aqfg== X-Received: by 10.159.55.229 with SMTP id q92mr1358707uaq.89.1477291518244; Sun, 23 Oct 2016 23:45:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.46.7 with HTTP; Sun, 23 Oct 2016 23:45:17 -0700 (PDT) In-Reply-To: References: Date: Mon, 24 Oct 2016 02:45:17 -0400 Message-ID: To: PHP Internals List Content-Type: multipart/alternative; boundary=94eb2c04ce682cbc8a053f96bc09 Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Object type hint From: tendoaki@gmail.com (Michael Morris) --94eb2c04ce682cbc8a053f96bc09 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Oct 23, 2016 at 3:39 AM, Micha=C5=82 Brzuchalski 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 neede= d > 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. > > Type hinting, along with the assert statement, provide a means to establish expectations for a methods. It's part of a coding paradigm known as 'design by contract' and it's critical for large teams and projects that are used among multiple teams. 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 also why objects are allowed to implement multiple interfaces, so that they can be labeled according to all the roles they can fulfill. 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. 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%21Asserti= on%21Inspector.php/function/Inspector%3A%3AassertAllObjects/8.2.x 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 object used). In summary, -1 to this as it encourages bad code writing. --94eb2c04ce682cbc8a053f96bc09--