[RFC][DISCUSSION] Strong Typing Syntax

2018-01-04 3:37 GMT+01:00 Michael Morris tendoaki@gmail.com:

Second Draft based on the feedback upstream.

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 loose typing rules. PHP is a weakly typed
language 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.

VARIABLE DECLARATION

PHP currently has no keyword to initialize a variable - it is simply
created when it is first referenced. The engine infers the appropriate type
for the variable, and this may be later cast to other types depending on
the context of the code. Objects can have magic functions to carry out this
casting such as __toString.

It is sometimes useful to explicitly state a variable's type. One case is
when the engine might incorrectly infer the type. For example "073117" is a
valid octal integer but also a date string in mmddyy format, so a
comparison with another date string in the same format could be... amusing.
While there is a string comparison function, that functions presence is
borne of the fact that we can't reliably compare "073117" with say,
"010216" because of the int casting possibility.

Since the scalar types have already been reserved as keywords they can be
used to declare variables in a manner not unlike C or Java.

int $a = 073117;

The var keyword is still around from PHP 4 days but is going unused. In
JavaScript var is used to formally declare a variable though it isn't
required (It remains important because without it JavaScript will search
the scope chain of the current closure all the way to the top scope. If it
doesn't find the reference it only then creates one. This can lead to huge
headaches so the creation of variables without using var is strongly
discouraged in JavaScript).

Since the keyword is available, let's make use of it.

var $a = "123";

What I propose this will do is formally declare $a, infer it's type, then
LOCK the type from casting. If further assignments are made to the variable
the quantity being assigned will be cast to type desired if possible,
otherwise a type error will be raised.

var string $a = $_POST['date'];

This syntax allows the programmer to choose the type rather than allowing
the engine to infer it. Here $_POST['date'] might be provided in date
string that might be confused for an octal int.

This magical casting is suggested because it follows the spirit of PHP, but
it may not be strict enough. For those the type can be explicitly declared
without using the var keyword as follows.

int $a = 4;

In this event a type error will occur on any attempt to assign a value to
$a that isn't an int.

The variable can still be re-declared in both cases so.

var $a = 4;
string $a = "Hello";

The var keyword can be combined with the new keyword to lock an object
variable so it doesn't accidentally change

var $a = new SomeClass();

As noted above a deliberate redeclare can still change the type of $a.

If $a is declared with an int type shouldn't it be enought to simply freeze
it's type
to int? var keyword was used in PHP4 and PHP5 and I suppose no one uses it
in PHP7 anymore, why not deprecate it? IMO it shoudl be burned&burried.

If all variable declarations with type would lock it's type then var
keyword would be
useless am I right?

ARRAYS
All members of an array can be cast to one type using this syntax

var string array $a = [ 'Mary', 'had', 'a', 'little', 'lamb' ];
int array $b = [1,2,3,5];

Personally I really don't like proposed syntax, there are some work in
progress
in subject of generics and IMO that should be the right way to declare
generic types.

Or members can be individually cast

var $a = [ var 'Todd', var 'Alex' ];
$b = [string 'id' => int 1, 'name' => string 'Chad'];

Again, following rules similar to the above. The main reason for doing
this is to insure smooth interaction with the pack and splat operators.

function foo (var string array $a = ...);

Here again why not just lock it's type here if we expect $a to be int. I
assume if someone
declares it as array or string he did it with some purpose.

And speaking of functions, that's the next section.

FUNCTION DECLARATION

Variables are also declared as arguments to functions. I propose using the
var keyword to lock the resulting variable and perform a cast if possible.

function foo( var string $a, var $b ) {}

Note that using var without explicitly calling type will be legal if rarely
used for consistency reasons. Also, someone might have a use for an
argument who's type could be anything, but won't change after it is
received.

The type can also be inferred from the default.

function foo( var $a = "hello" ) {}

This syntax is essentially doing a redeclare of the variable. This could be
very troublesome with references, so a Type error will result if this is
tried.

function foo ( var &$a = "Hello" ) {}

$b = 3;
foo($b);

With objects the var keyword can be used to prevent the function from
changing the object.

function foo ( var SomeClass $a ) {}

CLASS MEMBER DECLARATION

Variables also appear as object members. Following the pattern established
above their types can be locked. A couple note though

class SomeClass {

var $a = '3';
public var $b = 'hello';

}

This is awkward, seems like returning to PHP4 again. public is strictly
pointing out that
$a member is public and I suppose everyone got used to it.

For backwards compatibility the var keyword by itself must be equivalent to
"public". It is only when a scope operator is present that var takes on its
new meaning in this context.

Magic __set and __get cannot access variables with locked types because,
well, it will be a bloody mess. Basic getter/setter behavior (insuring the
datatype is correct) is accomplished just with the ability to type lock.
Beyond that explicit getters and setters will be needed, and once again an
inbuilt interface will be invoked. The interface is a little magical though
like the ArrayAccess interface.

class SomeClass implements AccessorInterface {

protected $a = '';
protected var $b = "string";
protected int $c = 5;

public get_a () { return $this->a; }
public set_b( $val ) { $this->b = (string) $val; }
public get_c():int { return $this->c; }

}

IMO there are better proposals for getters/setters in PHP RFC's.
You rely here on specific function naming which may collide or mess with
popular naming conventions.

Unlike userland interfaces, the AccessorInterface gets its potential method
names from the properties of the members as well as their signatures.
These methods follow the get_[varname] or set_[varname]. Getters must
return the same type as the underlying var if specified. Setters don't have
to take a matching argument as often their job is conversion.

CASTING INTERFACES

As these elements are introduced the ability of objects to control how they
are cast into scalars needs better improving. I propose interfaces in the
vein of ArrayAccess with the pattern below.

interface IntegerCastable {
public function CastToInteger():int;
}

PHP will call the function for the appropriate casting operation. Also, if
the object with at least one of these interfaces is echo'ed out then that
cast will be performed, in the priority order string, float, int, bool.

Note - The magic __toString and the StringCastable interface are mutually
exclusive - trying to create an object with both will trip a parseError.

COMPARISON BEHAVIOR
Controlling variable types gives us more granular control over comparisons
but determining which of the variables in a comparison can be coerced. When
a variable with a locked type is compared to another variable only that
other variable can be coerced.

Even better, comparisons between strongly typed variables are always strict
and a TypeError results if their types don't match. This actually provides
a way to force the greater than, lesser than, etc. to be strict.

PERFORMANCE IMPLICATIONS - TURNING IT OFF.
I imagine implementing all of the above will incur a performance hit. Yet,
pretty much all of this could be done with strategic use of assert(). PHP
is happy to not do this checking - much of it is for program testing and
peace of mind. So the last piece of the proposal is to insure all of the
above can be disabled.

I'm personally in favor if turning it off using the existing zend.assertion
flag since all these checks are part of Design by Contract anyway. In
addition to turning off all of the above I recommend allowing other
function type declarations to be turned off by zend.assertion.

There are reasons not to do that and use a separate flag for one or both of
these methods. While I can live with that I would like to point out that
debug flag proliferation can lead to confusion.

The crux of my argument for using the zend.assertion flag is that these
type checks are all, at the end of day, engine level assertions. PHP ships
with zend.assertion set to 1, and with PHP 8 we can keep that default and
recommend to providers to not assume it's safe to set it to -1 since there
is a small, but not insignificant, chance that old code relying on Type
declarations to be on might corrupt user data. I admit this would be
painful in the short term, but it is better for the long term health of the
language and parser.

CONCLUSION
I believe that covers all the bases needed. This will give those who want
things to use strong typing better tools, and those who don't can be free
to ignore them.

Please register a wiki account and put proposed RFC to the RFC's list.

--
regards / pozdrawiam,

Michał Brzuchalski
about.me/brzuchal
brzuchalski.com