Fwd: Re[2]: [PHP-DEV] PHP 8.1 enum const expressions problem
>>
>> Hello internals! I apologize if such a discussion has already taken
>> place, but I didn't find anything like it.
>>
>> When working with enums, I ran into problems that are currently not
>> resolved. In some cases, enumerations require self references and
>> constant arithmetic expressions:
>>
>> enum Example: int
>> {
>> case A = 0b0001;
>> case B = 0b0010;
>> case C = 0b0100;
>>
>> public const EXAMPLE_MASK = self::A | self::B; // << Invalid expression
>> public const EXAMPLE_MASK2 = self::A->value | self::B->value; // << Same
>> }
>>
>> Similar examples can be taken in the existing PHP code, for example,
>> for attributes (Attribute::TARGET_ALL) which is a binary mask for
>> existing «targets». Thus, if targets for attributes were implemented
>> through enumerations, and not through constants, then it would be
>> impossible to implement such functionality.
>>
>> In addition, enumeration values are not part of constant expressions,
>> so implementation through "Example::A->value" is also not available.
>>
>> Can you please tell me, maybe there have already been some discussions
>> of this problem? And if not, then maybe we should solve this problem
>> before PHP 8.1 release? Since it seems to me that the lack of such
>> functionality is quite critical.
>What you're describing is enum sets. That is, a value that is itself a union
>of two enum values. Those are not supported at this time. It's actually a bit
>tricky to do, since internally enum cases are not a bit value but an actual
>full PHP object. So self::A | self::B would be trying to bitwise-OR two
>objects, which is of course meaningless.
>
>The second doesn't work because technically self::A is an object, not a
>constant, so it cannot be used in a constant expression. The only dynamicness
>added in 8.1 was for "new" expressions in initializers. The objects don't
>exist at compile time so they cannot be reduced down to a constant value
>pre-runtime.
>
>I agree the current situation is suboptimal. I don't think anyone is opposed
>to enum sets, but they're a non-trivial amount of work to do and we haven't
>figured out how to do them yet. There's no simple way to address it as as bug,
>so any larger effort will have to wait for 8.2.
>
>--Larry Garfield
>
>--
>PHP Internals - PHP Runtime Development Mailing List
>To unsubscribe, visit: https://www.php.net/unsub.php
Yes, I saw this short description in your RFC (
https://wiki.php.net/rfc/enumerations ) about «enum sets». However, I do not
quite understand why we can not now add a cast to scalars (string and int) and
math expressions, which would solve this problem? This behavior has already
been implemented for GMP objects.
$mask = gmp_init(0b0001) | gmp_init(0b0010); // object(GMP) { num = 3; }
echo $mask; // 3
$mask = $mask + 1; // object(GMP) { num = 4; }
$mask instanceof \GMP; // true
I mean, for such cases, we can create a new "virtual enum case" containing a
new value instead special «EnumSetCase».
enum Some: int
{
case A = 0b0001;
case B = 0b0010;
}
var_dump(Some::A | Some::B); // enum(Some::@anonymous) { value = 3; }
I don’t think that it is necessary to consider the «enum sets» as a separate
case, cause addition is also a fairly popular case:
case LAST = self::B + 1;
Like any other mathematical operations.
--
--
Kirill Nesmeyanov
[PHP-DEV] PHP 8.1 enum const expressions problem
Hello internals! I apologize if such a discussion has already taken place, but
I didn't find anything like it.
When working with enums, I ran into problems that are currently not resolved.
In some cases, enumerations require self references and constant arithmetic
expressions:
enum Example: int
{
case A = 0b0001;
case B = 0b0010;
case C = 0b0100;
public const EXAMPLE_MASK = self::A | self::B; // << Invalid expression
public const EXAMPLE_MASK2 = self::A->value | self::B->value; // << Same
}
Similar examples can be taken in the existing PHP code, for example, for
attributes (Attribute::TARGET_ALL) which is a binary mask for existing
«targets». Thus, if targets for attributes were implemented through
enumerations, and not through constants, then it would be impossible to
implement such functionality.
In addition, enumeration values are not part of constant expressions, so
implementation through "Example::A->value" is also not available.
Can you please tell me, maybe there have already been some discussions of this
problem? And if not, then maybe we should solve this problem before PHP 8.1
release? Since it seems to me that the lack of such functionality is quite
critical.
--
Kirill Nesmeyanov
[PHP-DEV] The @@ is terrible, are we sure we're OK with it?
However this syntax allows it to be used on 7.4 unlike any other.
This means that the initial transition of library functionality to it will be
very smooth and will not require a separate implementation of polyfills for the
syntax of doctrine annotations and attributes.
With any other syntax, this would require implementing 3 separate attribute
classes and a bootstrap for them:
```
/** @Annotation */
class MyAttribute extends BaseAttribute {}
/** @Annotation */
@@\Attribute
class MyAttribute extends BaseAttribute {}
abstract class BaseAttribute {}
// and bootstrap
if (version_compare(PHP_VERSION, ‘8.0’) >= 0) {
require __DIR__ . ‘/polyfill/MyAttribute.php’;
}
```
For Rust-like `#[xxx]` nothing of this is required.
>Среда, 22 июля 2020, 20:09 +03:00 от tyson andre :
>
>Hi Derick,
>
>> Please, let's do the sensible and use the Rusty #[...] syntax.
>I'd probably re-vote for `<>` given the fact that `@@` may
>introduce similar parsing ambiguities in the future
>that may interfere with future language changes. (but those issues are not a
>certainty)
>
>I think that `#[` has its own issues, but am open to re-voting on it.
>For example, the following snippet would get parsed differently in PHP 7.4 and
>PHP 8.0, given a hypothetical JIT annotation for Opcache.
>With <>, it would give people a clear indication that the file
>required PHP 8.0,
>but a one-line annotation might be silently treated differently in many subtle
>ways in 7.4.
>It's probably possible to amend the parser make it an error to put the
>function declaration on the same line or to have other `#` comments
>within a multi-line #[ annotation,
>but I really dislike the special casing it would add.
>
>```
>$function = array_filter(
> $values,
> #[Opcache\Jit] function(int $x) { return $x % 2 > 0; }
>);
>```
>
>Cheers,
>- Tyson
>--
>PHP Internals - PHP Runtime Development Mailing List
>To unsubscribe, visit: https://www.php.net/unsub.php
>
--
Kirill Nesmeyanov
Re[2]: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?
I completely agree with this statement. Moreover, I had to write a full-fledged preprocessor in order to implement library functionality, suitable for both attributes and doctrine annotations (for version 7.4 and below). Rust-like syntax (#[xxx]) is both visually pleasing and creates much less problems when implementing such functionality. Note how easy it will be to adapt the new attribute syntax to support them using the doctrine annotation reader: https://habrastorage.org/webt/w-/dv/vf/w-dvvfygpwdtsmjlcyrr9qxocd0.png The currently accepted "atat" syntax requires the implementation of 4 classes and a bootstrap file that forcibly loads the necessary ones and replaces the files for a specific version of the language. This is exactly the reason why I had to write a preprocessor... >Среда, 22 июля 2020, 16:58 +03:00 от Côme Chilliet < >come.chill...@fusiondirectory.org >: > >Le Wed, 22 Jul 2020 13:00:10 +0100 (BST), >Derick Rethans < der...@php.net > a écrit : >> Please, let's do the sensible and use the Rusty #[...] syntax. >This syntax is the one I liked the less in the proposed choices, given # is > used for comments. > >Wouldn’t #[] cause more parsing issues than @@? > >What would be the rule, it’d be illegal to start a comment content with '['? > >Côme > >-- >PHP Internals - PHP Runtime Development Mailing List >To unsubscribe, visit: https://www.php.net/unsub.php > -- Kirill Nesmeyanov -- -- Kirill Nesmeyanov
Re[2]: [PHP-DEV] [RFC] FFI Improvements: Consistency and soliving some problems
> One other thing that probably also should be addressed is the
> behaviour around closures that was noted in the RFC
> https://wiki.php.net/rfc/ffi#php_callbacks :
During work with FFI, I did not encounter problems associated with this. There
are more significant ones, for example, the lack of a cast of types in
structures:
$struct = FFI::cdef(‘struct Test { char* string_field; }’)->new(‘Test’);
$struct->string_field = «string»; // Error
However, these internal problems including a memory leak when working with
anonymous functions, I found it unnecessary in this RFC. Maybe a little later.
> So rather than FFI::cdef() it could be FFI::ghij() or maybe even a
> name that is somewhat meaningful.
I'm afraid in this case, developers will use an easier to use feature. And this
means that just so we can’t deprecate it later.
However, if this argument is not very convincing, then as the name of the new
function, I would suggest «FFI::fromSource(...)».
>Четверг, 9 июля 2020, 11:01 +03:00 от Dan Ackroyd :
>
>On Mon, 6 Jul 2020 at 22:37, Кирилл Несмеянов < n...@xakep.ru > wrote:
>>
>> I would like to start discussion about the «FFI Improvements» RFC. At the
>> moment, I do not have the right to create wiki page, so I post it on the
>> github:
>> https://github.com/SerafimArts/php-rfcs/blob/ffi-improvements/rfcs/-ffi-improvements.md
>>
>
>Thanks for starting this discussion. I think FFI definitely needs to
>be improved before it will see widespread adoption.
>
>> Please note that for backward compatibility, allow option with
>> passing a string as the second argument to the FFI::cdef() method.
>
>Rather than changing the function signature of FFI::cdef, I think it
>would be better to introduce a new function, and then at some point
>deprecate and remove the old one (if anyone cares to).
>
>So rather than FFI::cdef() it could be FFI::ghij() or maybe even a
>name that is somewhat meaningful.
>
>For FFI_LIB, FFI_SCOPE, and FFI_LIB_DIR your proposal sounds sensible.
>It would be really good if someone involved in getting FFI into core
>could comment if there was any specific reason for not doing that
>already.
>
>One other thing that probably also should be addressed is the
>behaviour around closures that was noted in the RFC
>https://wiki.php.net/rfc/ffi#php_callbacks :
>
>> It's possible to assign PHP closure to native variable of
>> function pointer type (or pass it as a function argument).
>> This works, but this functionality is not supported on all libffi
>> platforms, it is not efficient and leaks resources by the end of
>> request. It's recommended to minimize the usage of PHP callbacks.
>
>I really don't know what can or should be done for that, but having a
>feature that can't be used safely seems like a bad feature.
>
>cheers
>Dan
>Ack
>
>--
>PHP Internals - PHP Runtime Development Mailing List
>To unsubscribe, visit: https://www.php.net/unsub.php
>
--
Kirill Nesmeyanov
[PHP-DEV] [RFC] FFI Improvements: Consistency and soliving some problems
Hi all! I would like to start discussion about the «FFI Improvements» RFC. At the moment, I do not have the right to create wiki page, so I post it on the github: https://github.com/SerafimArts/php-rfcs/blob/ffi-improvements/rfcs/-ffi-improvements.md The proposal: - Contains improvements regarding the harmonization of supported FFI directives («define FFI_XXX») in different operating modes (cdef and load). - And he suggests solving the problem of the inability to work with some types of libraries that contain loading of other libraries. In addition, I want to add that I am not a C developer, and I understand that this reduces the chances of adopting this RFC. However, I think that the proposal is useful and if approved, someone will help to implement it.
