Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:62199 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 84073 invoked from network); 15 Aug 2012 18:33:48 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 15 Aug 2012 18:33:48 -0000 Authentication-Results: pb1.pair.com smtp.mail=nikita.ppv@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=nikita.ppv@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.170 as permitted sender) X-PHP-List-Original-Sender: nikita.ppv@gmail.com X-Host-Fingerprint: 209.85.217.170 mail-lb0-f170.google.com Received: from [209.85.217.170] ([209.85.217.170:56848] helo=mail-lb0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 91/B1-08779-B8BEB205 for ; Wed, 15 Aug 2012 14:33:48 -0400 Received: by lbbgp3 with SMTP id gp3so1084756lbb.29 for ; Wed, 15 Aug 2012 11:33:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RJsrf2GmBZ8mwjDllI960br44oT+iAXwmyi/FuzEU6U=; b=VzPR+cAUvbgch+yS0FhWCNe5QoA5q9cjLVb531yrFrB1mpHzJ6pwiTKH8houbg9on+ Z26tlcL5Hrqk5i3UiSN/SGqMqlgk0QOOIWELmy8XS5vbdO3Np2V95f6MRtAVqKs95k5K UUWEgKJ8MMrSru0Jsswh6mVYqrwrpgTSP3mhpAIauZJBHwybvyiEuxV3U52yfNls/qWx nakPG4tcWWB788+9j65g+zhUXIfsW8uBjWO3ajvn04MCTeiu6cCoB0cnsZvn5h3Z1oz1 ZnGCmrA3fZstbYV/N3gZHn4mX3xSNUB2zWwj6hEB9fiR7MR8lYsMwrk+A+QA9c0uSHjs 0cNA== MIME-Version: 1.0 Received: by 10.152.132.133 with SMTP id ou5mr20021702lab.45.1345055624555; Wed, 15 Aug 2012 11:33:44 -0700 (PDT) Received: by 10.152.122.51 with HTTP; Wed, 15 Aug 2012 11:33:44 -0700 (PDT) In-Reply-To: References: <502A86AA.2030203@sugarcrm.com> Date: Wed, 15 Aug 2012 20:33:44 +0200 Message-ID: To: Kris Craig Cc: Anthony Ferrara , Stan Vass , Stas Malyshev , Levi Morrison , internals@lists.php.net Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [PHP-DEV] Inline typecasting / typehinting for classes and interfaces From: nikita.ppv@gmail.com (Nikita Popov) On Wed, Aug 15, 2012 at 8:15 PM, Kris Craig wrote: > On Wed, Aug 15, 2012 at 4:48 AM, Anthony Ferrara wrote: > >> Stan, >> >> On Wed, Aug 15, 2012 at 3:57 AM, Stan Vass wrote: >> >> > Hi! >> >> >> >> I agree with you. The one case where this syntax may be very useful is >> if >> >>> we want to implement class casting. So introduce a pair of magic >> methods >> >>> >> >> >> >> I do not think we want to implement class casting. I'm not sure how >> >> class casting even makes sense - if the object is of one class, how can >> >> you just make it into another class by casting? If you mean "casting" >> >> actually returns another object of different class, then just make a >> >> method for that that returns that object, I do not see how obscuring the >> >> purpose of this operation with unobvious syntax would help. >> >> >> > >> > The discussion is starting to drift very far from my original proposal. >> > >> > Instead of trying to guess what I mean, can't people just refer to my >> very >> > simple definitive proposed behavior? >> > >> >> My point was that what I posted was the only way that I can see for the >> original proposal to be useful. >> >> Anthony >> > > Though I'm clearly in the minority on this, I for one think this proposal > does have more merit than is being argued. There seems to be general > agreement all around that this would provide a benefit as it pertains to > code readability-- Not just by humans, but theoretically by doc/etc parsers > as well. > > This is where we get into arbitrary, subjective territory. To me, that > benefit in and of itself is sufficient to warrant this feature. To many of > you, it is not enough. > > The tie-breaker for me is the fact that, though the benefits are modest, > there's really no noticeable cost, either. The argument seems to, > essentially, break down as follows: "This feature isn't worth our time." > .... "Yes, it is!" .... "No, it isn't." Every feature has a cost, even if that cost is just maintaining the code. Doing language changes for minority use cases, which already have sensible solutions, doesn't make much sense. Another aspect here is that there is no reasonable syntax for this feature, at least I can't think of one: * The syntax `$foo = (InterfaceName) $container->service` is completely out of question. It looks like a cast, but wouldn't actually do a cast. * Same is to be said about `InterfaceName $foo = $container->service`. This syntax implies that the $foo variable will always be of type InterfaceName, even if it is later reassigned. It's not a sensible syntax for a one time validation * The other three syntaxes that were mentioned were just as unclear. E.g. `$foo = $container->service as InterfaceName` again looks like a strange cast syntax and `$foo = $container->service is InterfaceName` looks like the assignment should evaluate to a boolean (i.e. `is` is some kind of `instanceof`). On the other hand, the current ways of accomplishing the same goal are well-established and easy to understand: * Using a docblock: /** @var $foo IntefaceName **/ * Using an assertion: assert($foo instanceof InterfaceName). I think that the assertion is a rather concise and clear way to do this. It is much more obvious than some new and obscure `$foo = (InterfaceName $container->service)` syntax. Nikita