Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:89971 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 79652 invoked from network); 3 Jan 2016 03:59:23 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 3 Jan 2016 03:59:23 -0000 Authentication-Results: pb1.pair.com smtp.mail=php@golemon.com; spf=softfail; sender-id=softfail Authentication-Results: pb1.pair.com header.from=php@golemon.com; sender-id=softfail Received-SPF: softfail (pb1.pair.com: domain golemon.com does not designate 209.85.215.44 as permitted sender) X-PHP-List-Original-Sender: php@golemon.com X-Host-Fingerprint: 209.85.215.44 mail-lf0-f44.google.com Received: from [209.85.215.44] ([209.85.215.44:35909] helo=mail-lf0-f44.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 4A/83-33667-A9C98865 for ; Sat, 02 Jan 2016 22:59:22 -0500 Received: by mail-lf0-f44.google.com with SMTP id z124so255513023lfa.3 for ; Sat, 02 Jan 2016 19:59:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=golemon-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=mk6fky12xRVIMvQgvc0BcT5lUCtKDGuzp+tpE6VYOB8=; b=c5G/iqUUV6pc1BO1Vh8yweShb8GiRssMYz7w/OD/fnUmM32M8u5xmGAyTtciSbw5xV pfstv2iNZUtA09qbZtP76id11DCkaQgDlfP0mBGF5oqb/ODnFXiYVvI1sX+Pdo+ojbNx Go8Y+4sqznOMqjieanWMFkIpJ48fgqzWtQHCN/XpEsjicsocbHUZbS+wBCyD0YvIRop8 Nns0pVibhyBchmPjPwlQua1xDCRqrCEjRztJTMj77aECTerTCpp/V4zoiGNceWrjHwON yAD/gI+DG6oTTjhgi/n29OGobDGRwzrISY5Ddzyz8hVvCZh4lLeqJgqGIzZGzWEFbDAW 6ZvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=mk6fky12xRVIMvQgvc0BcT5lUCtKDGuzp+tpE6VYOB8=; b=UWe/n9InheHxPJ8p+dn/doiQOT4Kd9uY9skxBJlmDnyW9MAf39gVvUVSZ/eBf5MO1G i6wMwEpSUPZYV7A3/kaiaKvJfgCGbKU3d45TX0zXyZ0Lpws2LNI0mr9poo9BlZV6K6zm +Rn2EZlRzi3/v1Gw3AYJlcJ2y1Vn/jUrXs0MqPYRv2C/rRbQ/HTcnOHDpOuiVcPGbdrt RxTHVPogBVMoONGWHZZUVtNCkwyKBvBhCiz4WJFGITHNNi1QFqMrDIqrUmIIkgXqqomC IDJBElS4I67Q84Brh+3usHt2Eh20LuOm4ovcf3FDOiMVyvzqstY4SP3tdHXb4Bkhfnmh YfTw== X-Gm-Message-State: ALoCoQnsMFtcgKVmjGamqvSvJZobPve5Xihni7LsRGE4ipMUV4RZbk3F663bOjzdN/fDmh18QojxZu8tZm8uVrgTQCqBzG4ODQ== MIME-Version: 1.0 X-Received: by 10.25.91.139 with SMTP id p133mr8458134lfb.108.1451793558626; Sat, 02 Jan 2016 19:59:18 -0800 (PST) Sender: php@golemon.com Received: by 10.112.37.44 with HTTP; Sat, 2 Jan 2016 19:59:18 -0800 (PST) X-Originating-IP: [2620:10d:c090:180::b52c] In-Reply-To: <56888E9A.5020400@gmail.com> References: <56888E9A.5020400@gmail.com> Date: Sat, 2 Jan 2016 19:59:18 -0800 X-Google-Sender-Auth: ctCTGU_10VoxtOyYvEKFow_DGKs Message-ID: To: Stanislav Malyshev Cc: PHP internals , patriciotarantino@gmail.com Content-Type: text/plain; charset=UTF-8 Subject: Re: [PHP-DEV] RFC Operator Overloading in Userspace From: pollita@php.net (Sara Golemon) On Sat, Jan 2, 2016 at 6:59 PM, Stanislav Malyshev wrote: >> Patricio Tarantino has asked me to help him propose Operator >> Overloading in PHP 7.1 (based in part on my operator extension in >> PECL). I think we can expose this to usespace as magic methods with >> very little overhead (the runtime check and dispatch is already there, >> after all). > > We could, but I'm not sure whether we should. One of the reasons why > userspace operator overloading was kept out was that a lot of its uses > make code worse, not better. When you see expression that looks like > addition but you know it can do literally anything, that makes reading > the code so much more frustrating. I mean, you can *hope* * still means > "multiply", but you can't know it anymore. And there are not that many > types for which * has natural meaning. > I can't argue with you there. Magic can be exceedingly dangerous in the wrong hands. I think the core question of this RFC is: Is the responsibility to use magic safely something to grant PHP developers. I'm personally not decided on it, which is why operator stayed a PECL extension and it's taken someone else to put the RFC forward (even if I am sponsoring him to get the discussion rolling). > Additionally, introducing about 9000^W^W a lot of new magics drastically > raises both cognitive complexity of the language (now we have 14 magics, > adding operators (and RFC lists only arithmetic ones, though one may say > why stop there - C++ certainly didn't) more than triples that count. > I think this can be handled by taking Bishop's suggestion. After all, it's how it's actually implemented internally via do_operation. We could apply the same to the userspace callback and simplify the implementation details, even if it add slight complexity to script implementations. > Also, implementing them in consistent fashion would be non-trivial, and > imagine what fun would be had when +, += and ++ work differently > Hilarious to hear you cite that as the already existing inconsistency between += and ++ with non-numeric strings came up only last week. $x = 'foo'; $x++; // $x === 'fop' $x += 1; // $x === 1 But I digress, your point is taken, and it comes back to the same thing in my first paragraph response. I think we can all agree that the potential for evil is great, the question is whether or not we trust developers with great power. > (btw, why have different implementations for + and += at all?). > Because the former would typically result in a new object, the latter wouldn't. In the case of GMP it's the difference between: $x = new GMP(1); $x = $x + 1; // Makes a new GMP instance and replaces $x $x = new GMP(1); $x += 1; // Updates the internal value of the GMP instance That's a significant difference in terms of semantics if there are other references to $x lying around. Nevermind the cost of newing/cloning/destroying objects when all you really wanna do is mutate an existing one a bit. > And then we get questions of commutativity and associativity... > Yeah, this was always one of my annoyances of pecl/operator. Honestly, I could see making them always-left-associative to avoid some unforseen wtf. But (if combined with the additional operations) would require resolving the commutativity that happens in ZEND_AST_GREATER* (not terribly complex to handle, but we'd have to decide to do it). > What I'm trying to say, doing proper operators set is not that trivial, > and besides a very small set of use cases, I'm concerned it would be > used to write very clever write-once read-never code instead of good code. > Not arguing with that at all. :) -Sara