Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:101130 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 90604 invoked from network); 12 Nov 2017 18:25:59 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 12 Nov 2017 18:25:59 -0000 Authentication-Results: pb1.pair.com smtp.mail=rowan.collins@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=rowan.collins@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.44 as permitted sender) X-PHP-List-Original-Sender: rowan.collins@gmail.com X-Host-Fingerprint: 74.125.82.44 mail-wm0-f44.google.com Received: from [74.125.82.44] ([74.125.82.44:55949] helo=mail-wm0-f44.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id EF/FA-15386-632980A5 for ; Sun, 12 Nov 2017 13:25:59 -0500 Received: by mail-wm0-f44.google.com with SMTP id 9so5629011wme.4 for ; Sun, 12 Nov 2017 10:25:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=yCn1eFvAvsb08YUtDdR+3CiDj4yLHht4iFjXV1ODN9s=; b=DAI+WFBUTXUKvarWeleAt5vY8lled51C9g/Hi0WaDvCEk8g3qD8MHVohw0qeJxMOYh O7V7O92a1KWeN5cgahvjjSF0ne2MM6d6+emoxfU3UUXcI6a1S5dHWs3J2SJbkXvF4mOb 99gMjph21mNhpeR+l+IsrxXRtq7Z6v+smn9pc6H/bzEBnpOJU4Y1i0T/tmSvPP0+9GcI VQwFaxVXeADNskQv4xAA4Zmvfn1jbrOyME+ASDeFmLng/kObKta4X5Z9TEOChnmjM85b V2z2SR50V5Wg6wsikByhv3hnoMWc/ViE5sfQ83iyVIIDmAYcsCrV/FpB946dlmrAHxsM RFOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=yCn1eFvAvsb08YUtDdR+3CiDj4yLHht4iFjXV1ODN9s=; b=P94eAr3moxtSY1ftYYXvm3gd/la2rm9DlfO7eWtA6/lKmR74nczAjOqSWwL5a24hlP hFttBVJmipD1s4Ue+QB7Duiv1QbWUFRmjH2u0DCn9hNiRKhnpaIbrpE6UDVW8qX1dMMs 1sRXOZEziB11/WWEPT0A47o6QE2Vj1EHI1ztLY68M08ZyXB/MLQWKSHoEHnj5XIh2LoM jHz/QYkSwfXFhGLBlHIQ4suaZz5Ekm8IZ+Ii9ickM+j69vhEV8sLNRX2W6QauVTls5x7 4o6EiasMKfgjMpAX/jErjouHPg5qAODLCSBLyVqYemMgVKY6u8ZhfTdP0bvjCUcdjVH6 AcwA== X-Gm-Message-State: AJaThX61p3/O05gQJK4nxvEPRNP4d+dn2yCuOfIvUAdh6Y6n7gkvZoR4 Ao74kpylseDk+LJOkr9XeNEv4w== X-Google-Smtp-Source: AGs4zMYAH47mZGJaVkVvlGiDOqkEaygIn+7Avxog90N2TQk9L6AaAvmAGBrsBfZeFQJ9V2/4nnb6hw== X-Received: by 10.80.136.4 with SMTP id b4mr9799558edb.155.1510511154179; Sun, 12 Nov 2017 10:25:54 -0800 (PST) Received: from ?IPv6:2a00:23c4:4b81:ae00:2da0:efb0:ba9b:c0eb? ([2a00:23c4:4b81:ae00:2da0:efb0:ba9b:c0eb]) by smtp.googlemail.com with ESMTPSA id n7sm12197513edl.12.2017.11.12.10.25.53 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Nov 2017 10:25:53 -0800 (PST) To: internals@lists.php.net References: <93a05192-ed34-2164-50f9-2799899b32d1@fleshgrinder.com> <4ee3d414-92e1-75c7-402f-16a37ed3016b@fleshgrinder.com> <3f093ce2-e00e-f210-6e35-de31eb2f4b07@gmail.com> <0061a0c9-328c-75cb-cf6f-8e444e9ea3c0@fleshgrinder.com> <2f555141-96e0-3bab-c191-1216747644a5@fleshgrinder.com> <3b592a4b-c56d-fd16-f977-7c9898fabf57@gmail.com> Message-ID: Date: Sun, 12 Nov 2017 18:25:50 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Subject: Re: [PHP-DEV] Constants and Access Modifiers From: rowan.collins@gmail.com (Rowan Collins) On 12/11/2017 09:49, Fleshgrinder wrote: > Other languages allow you to have a contract on fields. > > class A { const FOO: int = 42; } > class A { final static $foo: int = 42; } > > These are basically the same, as you already said. However, I added a > contract to both of them. Yes, I wondered whether to mention type constraints; certainly the previous, stalled, proposal would have added them directly on what I was calling "fields". The more I think about it, though, the more I think a separate notion of "properties" like C# would be a great way to add new constraints in a clear way. Consider "int $foo { public get; private set; }" as defining the following: - a field which like any other variable could theoretically have any value, but which will never be accessed except via the property definition - a getter method with the signature "function(): int" - a setter method with the signature "function(int $foo): void" It immediately makes sense why you can't assign by reference (the setter method doesn't take a reference, only a value). It also makes sense to have this present in an interface (the implementing class is obliged to have such a property, but may define explicit getter and setter methods rather than defaults). You could then also have syntax for a property with a compile-time value and no setter, but I'm not sure whether this meets your requirements. > There is one thing that differs for the const > and the field: a const value must be known at compile time, whereas a > field value does not. An important difference! > > class A { abstract public const FOO: int; } > class A { abstract public function foo(): int; } > > These also look basically the same. The return value of the method, > however, may also be determined at runtime (just like with fields) and > on top of that might change with every invocation. What I'm not really clear on is *why* the value being known at compile-time is important to you. Is there some architectural decision you would make differently based on this guarantee? Are you expecting the language itself to have some optimisation or different behaviour based on that guarantee? Would the ability to mark a function as "pure" (always returning the same output for the same input) serve the same purpose, since a pure function with no arguments can be substituted for its return value at compile time? abstract class A { abstract static pure function getFoo(): int; } class B extends A { static pure function getFoo(): int { return 42; } } class C extends A { static pure function getFoo(): int { return 999; } } Regards, -- Rowan Collins [IMSoP]