Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:125491 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id 6D82E1A00BD for ; Tue, 10 Sep 2024 18:32:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1725993265; bh=Uanvs1EMY+YGfekQgOcqzxekhC98gvEkaI1PosrcSmQ=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=B24gVYeNX5N93u0V1t+DbRKDwD0D+HUeg1M5eICp/sp06b6mfj+Ge7xyMEaP0sdlo 1/Z5FaRV7gKhpW/060bWPaOxuE/TTigJ8FJXsBDc2eumNQOC9ebmrB8qaprHtNcKXb /giI7xd0t5XakHpO985wLop3MqVKbOe4Micvmg5vOMxOdfaIIl/SNa1mFKyNf43XLi 5+ana3nbLTzb4D9EiNbcWKfZjCeCq21VVzxapQ6tCOWqogl8rAY9mI1yeGUdurUUKV 2cJwU8AOUiflgszo76Nq9+nDk3mJLMoiPGN0Oe1eValYWrpqUdotDZSkEETkHXUzwp CJxYsDUEX3XAg== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 7E66018005B for ; Tue, 10 Sep 2024 18:34:24 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DMARC_MISSING,HTML_MESSAGE,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from mail-yw1-f173.google.com (mail-yw1-f173.google.com [209.85.128.173]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Tue, 10 Sep 2024 18:34:23 +0000 (UTC) Received: by mail-yw1-f173.google.com with SMTP id 00721157ae682-6db449f274fso44274957b3.2 for ; Tue, 10 Sep 2024 11:32:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=newclarity-net.20230601.gappssmtp.com; s=20230601; t=1725993142; x=1726597942; darn=lists.php.net; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=rpWklKUg+O6VCYpK2BSySSmcaGW77AsZYy8gimRi2kM=; b=wc3ck3Q9rolDfwMOTp+CT4poGlFc5/3AWIQwZy+TdGxL7mGM9I74v4hytz9gd3WZ98 OFzyrxpU/6pwz3FHsPsdOPmbfxZ+T6juOukmanQhW73fKVdaWvd923UbvVs7MMlTObHx co+s1w/lscB9k0c4ufpWwzC4U3LsbX7Jz23uwylIaGsDE7ghKUgODDiEQZ/mVWdb1mmt pFx89ohBghCpRc2hMO/GeWsVf00VnfbAd8JIE0oJAM9MBT9E1FCQQBDfE6NHScCllGl6 HAFPJdXt4jiMqHiCgVKT/1ScHgRUT39fNfs2mFHB9MbOWE7PX1HefEXZL3GFh00YVT64 6BRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725993142; x=1726597942; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=rpWklKUg+O6VCYpK2BSySSmcaGW77AsZYy8gimRi2kM=; b=AnHulz2pZPbuFObPYwcpSK+5sFpUT6MxChzqgDVjWXX4HrXDbtq2pgN2/0VMJkReEB 5nKjgQu7PTG/YPZTeXc4CZXdUG/8sZVR0Qh08jGfbU8G+M72oDgRj6hwgSY2CTqQ4YjH hiev2HtpQZjkpx55rRF0Rm8nAr/c2kgjrmBNRyo/5TxpuR++zrrETcitW3GSmBKInK+j HHf6P2aWpFmd/bF+K4yyI6uDg2jz5d88kCBwRSBnVHWewzk7GchTOnrP6fE5nbDPH+KJ PcF2nKzDGhZHAjDYhifw1bUjZyC/38QKm89WyEmLylO0HecyQTbcuRlbT6EDWxYWnsEi xkFQ== X-Gm-Message-State: AOJu0YypBw2AjfWy7d1DxGJYWMcPvqjEVtZUKWgQiOT/s5MA3IqFoq4p KqRZcU4zWLkpetQU0j2u44DCFnzzrdcBBJxKcVHBxExg84oRO+De1Ox72Ek3pZGIjxR9/bsB11n 4etM= X-Google-Smtp-Source: AGHT+IGI4ptlYD8cs8fX2yFGnkOr5/rpsaXBhwWuY7lvvyj3yRCVKs72CLZB5GvsLGSs2UHyOUbk5g== X-Received: by 2002:a05:690c:338c:b0:6ae:486c:59f with SMTP id 00721157ae682-6db4516c9a8mr174896187b3.29.1725993141836; Tue, 10 Sep 2024 11:32:21 -0700 (PDT) Received: from smtpclient.apple (c-98-252-216-111.hsd1.ga.comcast.net. [98.252.216.111]) by smtp.gmail.com with ESMTPSA id 00721157ae682-6db96531119sm3855977b3.143.2024.09.10.11.32.20 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Sep 2024 11:32:20 -0700 (PDT) Message-ID: Content-Type: multipart/alternative; boundary="Apple-Mail=_CAB7ABAF-7EE2-45F7-A1EE-2B090A6C5B85" Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.10\)) Subject: Re: [PHP-DEV] bikeshed: Typed Aliases Date: Tue, 10 Sep 2024 14:32:19 -0400 In-Reply-To: Cc: PHP internals To: Rob Landers References: <0fa39535-f22d-4eba-b4df-90abe39e683a@app.fastmail.com> <79e58673-50ec-461e-a998-736b020e4287@app.fastmail.com> <928A2984-6035-4DA6-9EA7-12E85237C270@php.net> <0d461700-1b6c-44fd-9cda-aa698de49847@app.fastmail.com> <667233C2-BC47-4530-8142-D90E6907FE63@daveyshafik.com> <63d241a8-a34a-498c-a5f9-f34230aa5afa@app.fastmail.com> <4C7A7F27-B787-44CA-B664-CEF4B9B412FB@newclarity.net> <212fd466-85bc-4447-90b7-8fe5426d1bd1@rwec.co.uk> <50CFF539-AD22-4F89-A65E-77AF76DBD63A@newclarity.net> X-Mailer: Apple Mail (2.3696.120.41.1.10) From: mike@newclarity.net (Mike Schinkel) --Apple-Mail=_CAB7ABAF-7EE2-45F7-A1EE-2B090A6C5B85 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Rob, > On Sep 10, 2024, at 4:31 AM, Rob Landers wrote: > This is very similar (behaviorally) to what I wanted to do with GMP. = Overloading GMP would have given you int-like powers in your type. The = biggest negative feedback I got was that people would abuse it still; so = we need some way to prevent abuse. If you read Jordon's operator = overloads RFC, and my GMP overloading RFC, you can see that users = basically need a way to define how to operate over even just an integer. >=20 > For example, Dollar(1) + Euro(3) is what? Or even Dollar(1) + 1? How = does a developer prevent someone from doing something nonsensical? The = language needs to enforce some rules and/or the developer needs to be = able to define them. These rules need to be intuitive and well reasoned, = IMHO. My arguments were that the use-cases where it is clear and objective = what each operator would mean are few and far between[caveat, see below] = and so rather than provide general operator overloading PHP should build = those use-cases into a core extension.=20 For example, to add Dollar + Euro, having a Money or Currency extension = as part of PHP core would make huge sense to me, but not giving everyone = the ability to overload operators for every type. I did not follow the GMP discussions as I have never needed to use that = extension in any of my own PHP development so I am not familiar with the = arguments made and may be mischaracterizing your proposal; correct me if = I do.=20 BTW, where is your GMP RFC? I searched for it but could not find it. = Did you propose operator overloading for GMP in core, or in userland? > For example, Dollar(1) + Euro(3) is what? Or even Dollar(1) + 1? How = does a developer prevent someone from doing something nonsensical?=20 If the rules are built into core, then the compiler and/or runtime stops = them from doing something nonsensical, right? > The language needs to enforce some rules and/or the developer needs to = be able to define them.=20 My argument is that the language should enforce those rules as allowing = the userland developer to overload operators will result in every = developer defining different rules for their own classes, leading to a = tower of babble. And the chances that many developers will do things = nonsensical with their operators approaches 100%.=20 I do acknowledge not everyone agrees with me on this, and if so that is = their right. If enough people disagree with me then PHP may eventually = have general operator overloading. My hope is that there are not enough = people who disagree. > These rules need to be intuitive and well reasoned, IMHO." =20 I hope anything that passes an RFC is intuitive and well reasoned = because otherwise our governance model is flawed and maybe we need to = address that first, if so? -Mike [caveat] =E2=80=94 I am aware there are likely numerous use-cases in = financial, scientific and/or related fields that could benefit from = operator overloading but that would likely never be mainstream enough to = make it into PHP core. For this I think making it easier to implement = operator overloading in an extension would be a reasonable solution (if = that is possible.) Yes, it would require people learn to develop = extensions, but working groups for those use-cases could form, and if it = could be done in a way that supports Zephir, then writing an extension = should not be too hard. https://zephir-lang.com = That, or come up with some way to limit operator overloading to only = those things where overloads are objectively obvious, but I really have = no idea what kind of limits could do that and I doubt it is even = possible. And if none of those things then those communities can get by with what = they have always been able to do; use methods and parameters. One thing = is clear to me, PHP is never going to overtake Python (or Julia, et. = al.) in those communities, so why appeal to a base that is not really = interested except on the periphery? OTOH, Python is not likely to = overtake PHP for general web development no matter how "popular" it = becomes. BTW, why has nobody ever mentioned Zephir on this list (that I am aware = of?)= --Apple-Mail=_CAB7ABAF-7EE2-45F7-A1EE-2B090A6C5B85 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Rob,

On Sep 10, 2024, at 4:31 AM, Rob Landers = <rob@bottled.codes> wrote:
This = is very similar (behaviorally) to what I wanted to do with GMP. = Overloading GMP would have given you int-like powers in your type. The = biggest negative feedback I got was that people would abuse it still; so = we need some way to prevent abuse. If you read Jordon's operator = overloads RFC, and my GMP overloading RFC, you can see that users = basically need a way to define how to operate over even just an = integer.

For = example, Dollar(1) + Euro(3) is what? Or even Dollar(1) + 1? How does a = developer prevent someone from doing something nonsensical? The language = needs to enforce some rules and/or the developer needs to be able to = define them. These rules need to be intuitive and well reasoned, = IMHO.

My arguments = were that the use-cases where it is clear and objective what each = operator would mean are few and far between[caveat, see below] and so = rather than provide general operator overloading PHP should build those = use-cases into a core extension. 

For example, to add Dollar + Euro, having a Money = or Currency extension as part of PHP core would make huge sense to me, = but not giving everyone the ability to overload operators for every = type.

I = did not follow the GMP discussions as I have never needed to use that = extension in any of my own PHP development so I am not familiar with the = arguments made and may be mischaracterizing your proposal; correct me if = I do. 

BTW, where is your GMP = RFC? I searched for it but could not find it.  Did you propose = operator overloading for GMP in core, or in userland?

For example, Dollar(1) + Euro(3) is what? Or even Dollar(1) + = 1? How does a developer prevent someone from doing something = nonsensical? 

If the = rules are built into core, then the compiler and/or runtime stops them = from doing something nonsensical, right?

The= language needs to enforce some rules and/or the developer needs to be = able to define them. 

My = argument is that the language should enforce those rules as allowing the = userland developer to overload operators will result in every developer = defining different rules for their own classes, leading to a tower of = babble. And the chances that many developers will do things nonsensical = with their operators approaches 100%. 

I do acknowledge not everyone agrees with me on = this, and if so that is their right. If enough people disagree with me = then PHP may eventually have general operator overloading. My hope is = that there are not enough people who disagree.

These rules = need to be intuitive and well reasoned, IMHO."  

I hope anything that = passes an RFC is intuitive and well reasoned because otherwise our = governance model is flawed and maybe we need to address that first, if = so?

-Mike

[caveat] =E2=80=94 I am aware there are likely = numerous use-cases in financial, scientific and/or related fields that = could benefit from operator overloading but that would likely never be = mainstream enough to make it into PHP core. For this I think making it = easier to implement operator overloading in an extension would be a = reasonable solution (if that is possible.) Yes, it would require people = learn to develop extensions, but working groups for those use-cases = could form, and if it could be done in a way that supports Zephir, then = writing an extension should not be too hard. https://zephir-lang.com

That, or come up with some way to limit operator = overloading to only those things where overloads are objectively = obvious, but I really have no idea what kind of limits could do that and = I doubt it is even possible.

And if = none of those things then those communities can get by with what they = have always been able to do; use methods and parameters.  One thing = is clear to me, PHP is never going to overtake Python (or Julia, et. = al.) in those communities, so why appeal to a base that is not really = interested except on the periphery? OTOH, Python is not likely to = overtake PHP for general web development no matter how "popular" it = becomes.

BTW, why has nobody ever = mentioned Zephir on this list (that I am aware of?)
= --Apple-Mail=_CAB7ABAF-7EE2-45F7-A1EE-2B090A6C5B85--