Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:101572
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.161.179 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <ee3d2ffc-a72c-78f3-281b-dd029c706105@gmail.com>
References: <CAEUnE0d+rHG-Rvjt7QAN6x6L+BP5Yb_cz8sGuOFDOkx-kCehkA@mail.gmail.com>
 <9a3a8760-f65a-a5c0-b318-1830a9a986c3@gmail.com> <CAH0Uv3H_DEPZ5HmaKGe08_DMrzndBz7ofJTUgeb4f66zeaj1EA@mail.gmail.com>
 <9352F6DF-9940-49A2-9B1D-FA9258E9738E@lerdorf.com> <bb4579ba-2e09-4199-a871-be4428a1ee2d@lsces.co.uk>
 <ee3d2ffc-a72c-78f3-281b-dd029c706105@gmail.com>
Date: Tue, 9 Jan 2018 17:06:54 -0600
Message-ID: <CAEUnE0eShfm4kZck=2gBef6cgU6DdrKggtotUK+Jyk6uPYOYFg@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="001a1141e72e91d39405625ff8bb"
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax
From: tendoaki@gmail.com (Michael Morris)

--001a1141e72e91d39405625ff8bb
Content-Type: text/plain; charset="UTF-8"

Before I begin, and without picking on anyone specific, I want to say that
it is generally unhelpful to say that because I, or others, do not know how
the engine is set up that it is impossible to make any meaningful
contributions to the list or on this issue specifically.  My clients don't
understand HTML.  If I told them they needed to study how HTML works before
trying to give me input on the sites I'm building for them I'd likely be
fired.  As a theater major I know quite a bit more than most of the people
on this list about what makes a good play or movie actually work, but I
don't pretend that knowledge is prerequisite to knowing if a play or movie
is good.  It either works, or it doesn't.

If the fallback to all suggestions is "Shut up, that's impossible to do
given current engine architecture." then I'm afraid that PHP is doomed to
become the next COBOL - a language with a lot of important legacy programs,
but no new developers or future as those old systems finally give up the
ghost. Also, given that HHVM has implemented at least one aspect if this
proposal with classes the argument that it's impossible carries a rather
large spoonful of salt.

This said, I will refrain from offering any more input on how this might be
implemented as it is clearly not wanted. I will instead focus on the
desired end state.


Much of what follows is based on Michal Brzuchalski's comments.  His
commentary can be largely summed up with "using the var keyword in a
counter-intuitive way is just going to make matters worse. Also,
getter/setter debates are quite a bit out of scope.



Third Draft.

Target version: PHP 8.

This is a proposal to strengthen the dynamic type checking of PHP during
development.

Note - this is not a proposal to change PHP to a statically typed language
or to remove PHP's current typing rules. PHP is typed the way it is for a
reason, and will remain so subsequent to this RFC. This RFC is concerned
with providing tools to make controlling variable types stronger when the
programmer deems this necessary.



DEFINITIONS
Before a meaningful discussion on types and type handling can be performed
some terms must be defined explicitly, especially since their definitions
in common parlance may change from language to language, and even
programmer to programmer. I

* Static Typing: This typing is performed by the compiler either explicitly
or implicitly.
* Dynamic Typing: This typing is performed by the runtime. Unlike static
typing it allows for varying degrees of variable coercion.
* Strong/Weak typing: These terms typically refer to the amount of latitude
the run time has to coerce variables - the more latitude the "weaker" the
typing.



VARIABLE DECLARATION (GLOBAL AND FUNCTION SCOPE)

PHP currently has no keyword to initialize a variable - it is simply
created when it is first referenced. The engine continually coerces the
variables into the required types for each operation. While this is a very
powerful ability, it runs into problems with comparisons (
http://phpsadness.com/sad/52 ). As a result of this issue PHP (and many
languages that share this problem such as JavaScript) provides the strict
comparison operator.  Avoiding this issue is one reason it can be useful to
have some amount of control over a variable's type. This can be
accomplished with two keywords, one old and one new: var and strict.

var $a = 5;
strict $b = 9;

Together these are "mutability operators" - that is they control if a
variable can mutate, be coerced, recast or what have you between types. The
strict keyword removes the mutability of a variable between types. The var
keyword restores it. The keywords perform these operations even in the
absence of an assignment, though using strict without any assignment will
lead to an error since type will be unknown.  Examples.

var $a; // $a will be created and be NULL.
strict $a; // TypeError - strict variables must have an explicit type or a
value from which a type can be inferred.
$b = 5;
strict $b; // $b locks down to integer since it was already declared. It's
value remains 5.
var $b; // $b's ability to be coerced is restored.
strict int $c; // Works. $c will be empty - any assignment must be the
specified type.
strict $d = 'Hello'; // Works. Type of string can be inferred.

Both keywords allow comma delimited lists of declarations (for
consistency), but strict will be the one to use it most frequently:

strict $a = 1, $b = "Hello", $c = 3.14, $d = [];

$a is inferred to int, $b to string, $c to float and $d to array.



FUNCTION DECLARATION

The strict keyword in a function declaration locks down the argument var
for the remainder of the function (or until var is used). For consistency
it is recommended that var be allowed as well, but it wouldn't do anything
beyond cuing IDE's that mixed will be accepted.

function foo (strict int $a, strict string $b, var $c, strict $d = true) {}



ARRAYS
If an array is strict all of its keys and values will be strict and
inferred on assignment.

strict $a = [
  'id' => 1,
  'name' => 'Mark',
];




CLASS MEMBERS

The var keyword appeared in PHP 4 to declare class members and found itself
deprecated. As the mutability operator it is still allowed, and now allowed
alongside the scope operator.

class SomeClass {
  var $a = '3';
  public var $b = 'hello';
  public strict $c = 3.14;
  protected strict int $d;
}

Interfaces can also lock member types following the above pattern.




COMPARISON BEHAVIOR
As mentioned above comparisons are the area where the most stability gains
are to be had. When strict variables are compared to dynamic or "var"
variables only the var variable will be coerced. If two strict variables
are compared a TypeError will raise barring an explicit cast

strict $a = 123;
strict $b = '123';

if ($b == (string) $a) {}

--001a1141e72e91d39405625ff8bb--