Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:110214 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 95211 invoked from network); 20 May 2020 12:31:45 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 20 May 2020 12:31:45 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 1D88C1804C2 for ; Wed, 20 May 2020 04:10:24 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-yb1-f170.google.com (mail-yb1-f170.google.com [209.85.219.170]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Wed, 20 May 2020 04:10:20 -0700 (PDT) Received: by mail-yb1-f170.google.com with SMTP id o134so775125ybg.2 for ; Wed, 20 May 2020 04:10:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=YTD9r4QDP01XH4Sa+TKuH06FY8Rx/hxVLfLNGgFKdcY=; b=SwR2/otIoHllzO8skqJFtymUBP1y+UrvER9E58DOv5WDXw6K0vh7K8rIP+x3vnMJOG Fi8MmtUiKetwzDCYm5AUtKcOQ4ozYQPpDCtzLnlO70ZaaxVg4qvBIXP6iCQDdqGVvGc9 a7A7fw6VSgP/ucAF0C7smcof6aSXB2dqCC0nVbALID4vupcOyo+ZJ89sfY0+HV0M6RC7 RPdCIADvP0Tz9T6gqgFrU86EqvdFv6L+BTFaJEoq3GghK88PlxO7POq2H/e6zCKOskQV yFOjJ4jgk0c1BG2QGMxtoduXNHyX/ZswDKMgGcuD/gOgZ3Yy7NPe+Q1nyu6gf4BcdXDN 66qA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=YTD9r4QDP01XH4Sa+TKuH06FY8Rx/hxVLfLNGgFKdcY=; b=c8agOZ6PP7ddcBLkeHcAkHmDpZoz8xecTHqc9ZDCDJNhYzxH0Fkjfmj+x4LMwKmZL3 0Q4qpUM+3ysUt4imAIav67OWqY0qw0ArWtXl06/qXLAq6ioRBL0pb/QMY810qvg5DjUx KQx69uJVPIJnQxcehWEbuk89xPwz8KyP+EDtYHQJ5YqfUov7jqYz31DZSHyxXgiUUgpi ISHzxbPdC/Uz9u7LmoGQpudVNOrCqRp/YqrAfgz1z/YZXW7CjFyDmXELfhhsj2TUO4X9 kgHufGhOC/qteQ8qLCEcLSQHIMHW7YDkLOAPG4/c+sQYKZN1yM7FUqWgwo1sGNl05o8E kViw== X-Gm-Message-State: AOAM531SR38lW5vKsVPOCcZGnkboAfkI2MAq86TkGyvJMtvz5zez4UNu rzHOJQxcQFYskuIA//fV39+L/1YGO/TlH4qAaDgqefIM X-Google-Smtp-Source: ABdhPJwaJ4s4Oad/e8TL+WQaT3UndxO4PKqCBeYIyzEoMHKPK4BoxRpoGcw97WejA8NoREPGDCOkX8/eDjkG/NLMm6s= X-Received: by 2002:a05:6902:72d:: with SMTP id l13mr6978269ybt.216.1589973019499; Wed, 20 May 2020 04:10:19 -0700 (PDT) MIME-Version: 1.0 Date: Wed, 20 May 2020 16:10:08 +0500 Message-ID: To: internals@lists.php.net Content-Type: multipart/alternative; boundary="00000000000007a25e05a612717e" Subject: PHP RFC about variables From: goootlib@gmail.com (=?UTF-8?B?0JPQu9C10LEg0JbRg9C60L7Qsg==?=) --00000000000007a25e05a612717e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If you look at Wikipedia, you can see that a variable in programming is a named, or otherwise addressed, area of memory whose address can be used to access data. The word from this definition to which I would like to draw your attention is data. Is it really so that in PHP and other programming languages in which we write, variables are used only for accessing data. In fact, in addition to access data, variables are also used to access objects, arrays and some other things. Data (strings, integers, floating-point numbers, boolean values), objects and structures (arrays) for a human are essentially different entities (abstractions), and it would be reasonable to handle them as different things, ignoring the fact that for the machine they are the same (named memory areas). In order to do this, I would like to propose (once again) to start to use entities such as, for example: object, structure, data instead of variables . This will help to greatly simplify the perception of the code, because you no longer have to keep in mind the data types of most variables= . Code: // If formerly, for example, to store objects in PHP, // we used variables that are declared in the current syntax using the $ symbol $objectVar =3D n= ew SomeClass(); // Now for the objects we will have a special entity =E2=80=9C= object=E2=80=9D, // which, for example, will be declared using the * symbol *objectEntity =3D n= ew SomeClass(); // "Structure" entities will be declared using ^ symbol ^simpleArray =3D ['one', 'two', 'three']; ^associativeArray =3D ['key' =3D>= 'val', 'another_key' =3D> 'another_val']; // And "data" entities using symbol % %string =3D 'abcde'; %integer =3D 123; %floating =3D 1.23; %boolean =3D tru= e; I want to make one point right away - my concept has nothing to do with the concept that is used in the PERL programming language, where each data type has a separate character. I urge only to enter one symbol for all scalar types, one symbol for objects and one for structures (arrays). The variables themselves and the symbol that is used to denote them ($) can be left for backward compatibility, as well as for types that are not covered by the new entities described by me, one of such types, for example, resource. The last time I proposed my idea for RFC, they refused me because allocating three new characters to implement it would be too wasteful. I do not deny that the remaining available characters should be used wisely. But in my opinion, in this case, the allocation of three new characters is quite justified by substantial benefits that this innovation brings. And due to the limited number of characters at the present time, it seems to me unreasonable to refuse futher progress. --00000000000007a25e05a612717e--