Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:107826 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 40807 invoked from network); 19 Nov 2019 18:01:39 -0000 Received: from unknown (HELO php-smtp3.php.net) (208.43.231.12) by pb1.pair.com with SMTP; 19 Nov 2019 18:01:39 -0000 Received: from php-smtp3.php.net (localhost [127.0.0.1]) by php-smtp3.php.net (Postfix) with ESMTP id EF98C2D1FBC for ; Tue, 19 Nov 2019 07:54:34 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp3.php.net X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS3215 2.6.0.0/16 X-Spam-Virus: Error (Cannot connect to unix socket '/var/run/clamav/clamd.ctl': connect: Connection refused) Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp3.php.net (Postfix) with ESMTPS for ; Tue, 19 Nov 2019 07:54:34 -0800 (PST) Received: by mail-il1-x12c.google.com with SMTP id n18so20098940ilt.9 for ; Tue, 19 Nov 2019 07:54:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=6DnOsTouVKP7GiEkclenPsOuNQ/aldiee0Pz26gGyeo=; b=Rsfgxc6PKEyhoSYRF2y4JEzzYdwBEk6SWjYQsELQSpHyVYznmRgCQ2fLhBp7CNPH0Q UFkqXRkrxtlqKWPMWXmeFCMM0cRd31xJcd4+S4uo4LrwKdU1JR4sn4pqdRftu+uKoFZS K0MNoJk8vrImSBaYUs0rkVa1WuOj+UunYbk7Ef6drAqSGCJlcJ6Iw6sqjThC2xywP6zq sCK31p2POACczQh2PjvN3030kwkGiHbT4GrTU11rhxtSXa6pyVduJQTyivlGJrlQHTnM VZDl66BiZ/Sz/XAqAti+m2kr10h7GyDmYBATFRYBEKwMH1LfZnnpXbCQjBd+ZWzjaRNK uBcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=6DnOsTouVKP7GiEkclenPsOuNQ/aldiee0Pz26gGyeo=; b=PMdxOlLvc6ELtbWvix0YiQ/+cG2c2HSPOJG+A7wfavxnzJA10phC+rgORf5xfnWoBA QUagLl3m/HTJIdp/OPl36nOQwyCZ0nsbaA5yDIOg5vXlSBHNwjAwWHRL1YMQN1F/TOns f4KcCXPwGVuV4hdvLwgi8+tmwhSrrIzQBANMfcu9jxfOwciZjQYNIGh9+qYbrLNbCR1O e9uI4oj02mBSMSZtJlje4++J6iEBmrbI5QIKiOV+CuCA1fCg7SPAKN0VE537DJ5N9Tx9 1FFFyAKp3tMISsc1sYfc6Fg5apuS7wQBg+iIFf6vXItFGRU4V+OiQxd83Ydq+0PA2Pdc oZqA== X-Gm-Message-State: APjAAAXnggC/NFWJfM9vDTitGZ3sVAjvd0rTvpQRP5dQ2xM67TJunWy8 6QnpyfoPPz/kNr5FfVYqT+ZLLjQjuqK77DjaooL3aCoY X-Google-Smtp-Source: APXvYqwFJOBHiHHcBqkXAlKVPwtliq4/naMX3OYNacKkwxV1hxodGwbmTc83ucJUs1GjKVtNShcyr8t5C1E9se0S/Kk= X-Received: by 2002:a92:c801:: with SMTP id v1mr20974321iln.253.1574178873427; Tue, 19 Nov 2019 07:54:33 -0800 (PST) MIME-Version: 1.0 References: <461958fe-182e-59bf-9fdb-b110fd09e2b2@aimeos.com> <08de5448-3c5a-ad32-555e-b8f9579c1337@aimeos.com> <7b527bbb-47e3-9b24-8766-c15e6334c78a@gmail.com> <1BF6C8EC-6DF1-4481-94B2-3A6E7D1312BE@newclarity.net> <2814FAA1-3BEC-47CF-A95E-AE61A33B7308@newclarity.net> In-Reply-To: <2814FAA1-3BEC-47CF-A95E-AE61A33B7308@newclarity.net> Date: Tue, 19 Nov 2019 15:54:21 +0000 Message-ID: To: PHP Internals Content-Type: multipart/alternative; boundary="000000000000904acd0597b51465" X-Envelope-From: Subject: Re: [PHP-DEV] Concept: "arrayable" pseudo type and \Arrayable interface From: rowan.collins@gmail.com (Rowan Tommins) --000000000000904acd0597b51465 Content-Type: text/plain; charset="UTF-8" On Tue, 19 Nov 2019 at 03:19, Mike Schinkel wrote: > Should we make decisions about future language enhancements based on > conflicting and impossible to forecast predictions, or when a significant > subset of PHP developers see value in a feature for their use-cases *and* > others can simply ignore if they do not want to use it? > Neither. We should discuss the advantages of the feature, the potential costs, and whether other features would be even better. I challenge that assertion that having a huge number of magic or standard > methods is the *"only"* way this provides benefit. > > Not the only way it can bring *any* benefit, but the only way it can bring the *particular* benefit of eliminating the need to agree method names across code bases. I think that's where this conversation has broken down a bit, which may be my fault: I wasn't intending to argue against all the possibilities of the feature, only the specific arguments you were raising. We disagree over whether (array)$foo would be used more consistently than meaningful method names, so maybe we should leave that there, and look at some other pros and cons of the feature. > Since conversion to array from object is a common need just this one > method could provide a similar level of benefit that __toString() already > provides. > > What makes __toString() worthy of a special case in my mind is that there are fairly common scenarios where variables are _implicitly_ cast to string: in double-quoted strings, echo, etc. Having the language be able to automatically call a particular method in those situations is therefore more valuable. I think I'd actually be more receptive to a proposal to allow _all_ casts to be overloaded, rather than adding array as a second special case, because *implicitly* casting to array doesn't seem like it would be any more common than other types. > Yes, if your class is named Transaction then isSuccessful() probably *is* > a better name than __toBool(). > > > But if your class name itself is isSuccessful()? > > Yes, I would see that as a better example. I think operator overloading in general makes sense when the object itself can be thought of as a special-case of the primitive it's emulating operators for. So in this case, the IsSuccessful class would be "a special kind of boolean"; and the hypothetical List or Collection classes I mentioned a couple of days ago would be "a special kind of array". We even have that in PHP for built-in types: GMP objects can now be used with mathematical operators like $foo * $bar, and those operations do what you'd expect them to do on an integer or float. Operator overloading can also be used just as a cute way of spelling something - probably most famously, C++ uses the << and >> operators for writing to and reading from streams, even though they're actually overloads of the bit-shift operator. This kind of use is, I would say, more controversial - going back to consistency, it's easier to reason about code if $foo * $bar always does some kind of multiplication than if it's been overloaded to mean "$foo is the star of $bar". Overloading of cast operators is no different - the clearest use cases for __toString() are where the whole class basically represents a piece of text, and the more controversial are where (string)$foo is actually a cute spelling of one method on a complex class. That's not necessarily a reason to not add a feature - any feature can be abused - but it potentially makes it harder for users to understand each other's code, and that's a cost we should at least consider. > Let me count the ways. Here are several examples: > > https://gist.github.com/mikeschinkel/361bbcf44da1dac0da6afd786b6b8c3a > > > A great example of this is the AllowedHtml class I wrote for the above > gist whose sole purpose is to streamline the specification of allowed HTML > using to KSES library. > > This is an interesting example. On the one hand, there is only one array ever going to be produced by that class; but on the other hand, the ultimate use of it is explicitly passing to a function that expects a different type. Assuming the same behaviour as __toString, the code shown would give an error under strict_types=1, and need changing to wp_kses((array)$allowed_html) A different interpretation would be that this is the Builder Pattern, and the target type happens to be an array rather than an object. So you might decide that the consistency you really needed is that all builders should have a build() method, and the last line of the example would become: $clean_html = wp_kses($_POST[ 'content' ] ?? null, $allowed_html_builder->build()); That doesn't mean the version you wrote is *wrong*, but should make us consider why one version deserves special treatment by the language and the other one doesn't. Regards, -- Rowan Tommins [IMSoP] --000000000000904acd0597b51465--