Will there be an option for "prune" option of the compiler? about compiler HOT 7 CLOSED

Something I've also been thinking about, especially when working on #118, which now generates a __get / __set combination to implement type-checking. PHP itself doesn't have a version of types to denote syntax only, do not check at runtime, as this is what people typically do by using apidocs. Still, for consistency, we might want to have syntactic support for this.

Here are some ideas:

// 1 - Use square braces - like optional notation in most Un*x command line tools' help
function fixture([string] $type) { ... }

// 2 - Use @ as prefix for the type, reminds of the error suppression operator, but also of apidoc
function fixture(@string $type) { ... }

// 3 - Use type unions essentially evaluating to no type-checking, the compiler could then omit this
function fixture(mixed|string $type) { ... }

// 4 - Use ? as suffix - putting the type in question (might be confused for ?string, which is nullable!)
function fixture(string? $type) { ... }

// 5 - Use ?? as suffix - the null-coalesce operator (might look weird in conjunction will nullable types)
function fixture(string?? $type) { ... }

// 6 - Use <> - inspired by https://wiki.php.net/rfc/protocol_type_hinting but might be confused for generics
function fixture(<string> $type) { ... }

// 7 - Use unchecked keyword
function fixture(unchecked string $type) { ... }

// 8 - Use special comments
function fixture(/* unchecked */ string $type) { ... }

// 9 - Use special attribute from the lang package
function fixture(#[Unchecked] string $type) { ... }

I currently favor the attribute approach, as it's syntactially compatible (which options 1 - 7 aren't) and would fall nicely in line with other attributes that could trigger compiler actions, like #[Deprecated] to trigger warnings or #[Override] to check whether we actually override anything. Implementation may be possible solely with the transformations API.

My second preference is the @-prefix as it's visually less cluttered. It would require a change to xp-framework/ast, a new unchecked member in the lang.ast.nodes.Property class and handling inside emitProperty(), and would not be the first time we went beyond the limits of PHP syntax - we support types like array<string>, for example.

So it depends on whether this is a rare case or whether you'd use this in lots of places, I guess...

What do you say? Either option would form a nice pull request, I think!

from compiler.

Another thought may be go for an even more generic annotation with https://wiki.php.net/rfc/internal_method_return_types merged to PHP 8.1. This change produces these kinds of errors with method signatures:

While in this case we can simply add Traversable as return type in all PHP versions, it doesn't work without breaking PHP 7 for the ArrayAccess methods - see xp-framework/core#276

// Correct for PHP 8.1, searches for a type named "void" in PHP 7.0
function offsetSet($offset, $value): void { ... }

// Only emit "void" for PHP 8.1+, uses version_compare() syntax
#[Checked('>=8.1.0')]
function offsetSet($offset, $value): void { ... }

We might also be able to solve this problem by always emitting the correct types in these situations in the PHP 8.1 emitter if no types are added.

Using null as argument for the Checked annotation would then never emit parameter type:

function fixture(#[Checked(null)] string $type): void { ... }

This, however, is quite some visual noise.

from compiler.

One idea that came to my mind is to be able to customize the emitter by adding and/or removing traits from it, thus overriding or revealing the default behavior, respectively.

$ xp compile -VirtualProperties +MetaInformation <in> <out>

from compiler.

Settled for the following:

• The default is to omit property type checks for PHP < 7.4
• Using xp compile -t php:7.0 -a php:virtual-property-types <in> <out>, code can be emitted that will generate type checks

The reason not to enable this emitter by default is that a) it doesn't work for static properties due to a limitation in PHP and b) the generated code is much slower than the native implementation - see #129.

from compiler.

// 2 - Use @ as prefix for the type, reminds of the error suppression operator, but also of apidoc
function fixture(@string $type) { ... 

See https://docs.hhvm.com/hack/types/soft-types - should we reconsider?

from compiler.

My original idea behind this issue was to keep the source code intact, and only decide whether we want to add additional runtime checking at the stage of compilation (to leave them off or try and backport them).

The softypes from hack are certainly a nice idea and are worth the consideration, but that's probably another topic.

from compiler.

and only decide whether we want to add additional runtime checking at the stage of compilation

@Danon - have a look at #158, would that meet your needs?

from compiler.