Re: [PHP-DEV] instance version of match ?
On Mon, Mar 28, 2022 at 7:56 PM Karoly Negyesi wrote:
> match ($object) {
> Someinterface => 'foo',
> AnotherInterface => 'bar',
> }
>
> this can not clash with any existing code as using identifiers like this
> are a syntax error currently.
That's valid code actually, see https://3v4l.org/BEcE4
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] instance version of match ?
Hi,
May I suggest adding a little "instanceof" magic to match? Like this:
match ($object) {
Someinterface => 'foo',
AnotherInterface => 'bar',
}
this can not clash with any existing code as using identifiers like this
are a syntax error currently.
Currently you could do the same with
match (true) {
$object instanceof Someinterface::class => 'foo',
$object instanceof AnotherInterface::class => 'bar',
}
Indeed, the former could be considered syntactic sugar for the latter. And
I do not think there's any ambiguity here for the casual reader or is it
just me who thinks no other sensible reading is possible?
Thanks for your consideration.
Karoly Negyesi
[PHP-DEV] Re: [VOTE] Undefined Variable Error Promotion
On 14/03/2022 17:18, Mark Randall wrote: I have started the vote for promoting undefined variable access to throw an Error exception. The vote will run for 2 weeks until March 28th 2022. https://wiki.php.net/rfc/undefined_variable_error_promotion The RFC has passed with 33 votes (80%) in favour and 8 against. Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Under discussion] Arbitrary string interpolation
Hi,
> A large part of that is because the placeholders are positional rather
> > than named, so you have to keep track of which is which; but by the time
> > you've got named placeholders, you might as well have variable
> > interpolation.
>
> I feel the same way. PHPStorm has a feature that highlights the given
> expression when your cursor is placed on a %s placeholder and vice
> versa. This seems to be the treatment of that symptom.
>
Has "add named placeholders to *printf()" been proposed/discussed before (I
didn't find)?
What about strtr() (e.g. `strtr('The {foo} is {bar}.', ['{foo}' => FOO,
'{bar}' => bar()])`)? (and even templating engines like Twig?)
Anyway, it sometimes baffles me indeed that I can build a string with a
method call like `"...{$foo->bar()}..."` but not with a function call like
`"...{foo($bar)}..."`, and also with complex interpolation via callable
variable like `"...{$foo($bar + baz($qux))}..."` but not with simple
constant like `"...{FOO}..."` or operation like `"...{$foo + 1}..."` :/
Regards,
--
Guilliam Xavier
Re: [PHP-DEV] Typed constants revisited
> Constants are not abstract in an interface - they must be assigned a
> value. Only classes and methods can be abstract. Within an abstract class
> it is not valid to have an abstract property. Properties can be defined
> `protected int $id;` and optionally assigned a value `protected int $id =
> 5;`, but cannot be `abstract protected int $id;`.
>
That's the *current* state of the language indeed, but to me, [part of]
your proposal looks like introducing "abstract constants"... Maybe I'm
misunderstanding?
> So to me it makes more sense to have constants follow the same syntax as
> properties `public const bool CAN_FLY;` without the `abstract` keyword.
>
> An example:
>
> ```
> abstract class Bird
> {
> public const bool CAN_FLY;
> protected bool $isExtinct;
> ```
>
> This allows for similar behavior, similar requirements, and similar syntax
> - consistency ftw!
>
For similarity/consistency, the `$isExtinct` property should probably be
[`public` and] `static` (actually `readonly` too, but cannot be both).
But, again, we can also see some similarity with `static` *methods*, e.g.:
```
abstract class Bird
{
abstract public const bool CAN_FLY;
abstract public static function isExtinct(): bool;
}
class Dove extends Bird
{
// NOTE: the following two lines are required (in the class definition)
public const bool CAN_FLY = true;
public function static isExtinct(): bool { return false; }
}
// var_dump(Dove::CAN_FLY);
// var_dump(Dove::isExtinct());
```
Besides, an uninitialized property must be initialized before first read,
but is *not* required to be overridden/redefined (with a value) in a child
class; so in this example (still hypothetical):
```
abstract class Bird
{
public const bool CAN_FLY;
public static bool $isExtinct;
}
class Dodo extends Bird
{
// NOTE: the following two lines are commented out
// public const bool CAN_FLY = false;
// public static bool $isExtinct = true;
}
var_dump(Dodo::CAN_FLY);
var_dump(Dodo::$isExtinct);
```
where would the [missing value for constant] error be: on the definition of
class Dodo (like for an unimplemented abstract method), or only when trying
to access Dodo::CAN_FLY (like for an uninitialized property)?
>
> There seems to be interest and good use cases (thanks Sara for the good
> practical example!). At this point I'm going to work on a new RFC with all
> the details and feedback from this discussion.
>
>
Thanks & good luck! =)
--
Guilliam Xavier
