Re: [PHP-DEV] [RFC][Discussion] Objects can be declared falsifiable
> While I understand the proposed feature is opt-int it introduces more magic
> that can be solved using more verbose and IMO cleaner solutions.
Understood and appreciate the position.
> This is somehow confusing, why is the $response storing object ref is ok
> while inclining the new object creation is not?
Not quite following, apologies.
Adding a different use case.
Allow for fully-specified custom collections; array being the compound type
that can resolve to false/empty based on count.
$array = [];
(bool) $array; // false
empty($array); // true
if ($array) {
// handle not empty
}
// handle empty
$array = [1, 2, 3];
(bool) $array; // true
empty($array); // false
if ($array) {
// handle not empty
}
// handle empty
Current state of PHP re custom collections (exclamation marks - ! - represent
difference compared to native array):
class MyCollection implements ArrayAccess, Iterator, Countable {}
$collection = new MyCollection([]);
(bool) $collection; // true - ! - because instance exists, regardless of
collection content
empty($collection); // false - ! - same reason as previous
if ($collection) {
// ! - handle empty and not empty
}
// ! - unreachable
$collection = new MyCollection([1, 2, 3]);
(bool) $collection; // true - because instance exists, regardless of collection
content
empty($collection); // false - same as previous
if ($collection) {
// ! - handle empty and not empty
}
// ! - unreachable
With RFC:
class MyCollection implements ArrayAccess, Iterator, Countable, Falsifiable
{
public function __toBool(): bool
{
return $this->count() > 0;
}
}
$collection = new MyCollection([]);
(bool) $collection; // false - because collection count === 0 - close to the
previous comment re single value under inspection
empty($colleciton); // true - same as previous
if ($collection) {
// handle not empty
}
// handle empty
$collection = new MyCollection([1, 2, 3]);
(bool) $collection; // true - because collection count > 0
empty($colleciton); // false - same as previous
if ($collection) {
// handle not empty
}
// handle empty
Alternative approaches for custom collection use case:
1. Modify Countable (most likely, if using alternative) to include empty() and
bool() methods.
Might feel more palatable despite not strictly limiting scope to the custom
collection use case.
Any class with Countable, for example, would also be able to resolve to false
or empty using SPL functions - including use in IF.
Allows for explicit (“verbose"), direct call of both methods by user should
they choose:
$collection->empty()
$collection->bool()
Instead of $collection->__toBool() OR something like $collection->__isEmpty()
Known drawback to using Countable would be in a possible future where there is
a separation between 0, false, and empty when it comes to type juggling in PHP.
Whereas using a Falsifiable interface leaves a simpler path of an Emptiness
interface; again, should the three be separated in the future.
2. Or, modify ArrayAccess to include the empty() and bool() methods.
This would restrict the behavior more toward the custom collection concept.
However, would lean more toward Countable due to the equivalence in PHP type
juggling and Countable using an integer: 0 == false == empty
Otherwise, similar to alternative #1.
3. Or, modify Iterator to include the empty() and bool() methods (or possibly
leverage the valid() method that already exists?); otherwise, similar to
alternative #2.
Cheers,
Josh
> On Nov 4, 2022, at 1:37 AM, Michał Marcin Brzuchalski
> wrote:
>
>>
>> if ($response->getStatusCode() > 199 and $response->getStatusCode() < 300)
>> {
>> // do something with “true” - which has a range of 100 possibilities at
>> a granular level, which we could respond to differently - possible to
>> interact with $response
>>
>> }
>> // do something with “false” - which has a range of more than 100
>> possibilities at a granular level, which we could respond to differently -
>> possible to interact with $response
>>
>> We might wrap response to create an isOk() method to move the conditional
>> logic somewhere within the object itself and make the call site more
>> readable.
>>
>> If ($response->isOk()) {
>> // do something with “true” - still able to interact with $response
>>
>> }
>> // do something with “false” - still able to interact with $response
>>
>
> This looks way much cleaner and is easy to read and understand.
> While I understand the proposed feature is opt-int it introduces more magic
> that can be solved using more verbose and IMO cleaner solutions.
>
>
>> With the RFC:
>>
>> if (new MyType($config)) {
>> // do something with “true” - can’t use MyType because not assigned
>>
>> }
>> // reachable because possible to resolve to false - if implements
>> Falsifiable and __toBool can resolve to false - can’t use MyType because
>> not assigned
>>
>> if ($response = new MyType($config)) {
>> // do
Re: [PHP-DEV] [RFC][Dynamic class constant fetch]
On Fri, Nov 4, 2022 at 10:49 AM Marco Pivetta wrote:
> What's convenient about `Foo::{$bar}` vs `constant(Foo::class . '::' .
> $bar)`? I'm a bit confused by this :|
>From the static analysis POV `Foo::{$bar}` is way better, as we can immediately
see that the code is trying to access a constant of a specific class,
and we can,
e.g., flag those operations that did not validate that `$bar` actually exists
as a Foo constant.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Dynamic class constant fetch]
Hi Ilija, pt., 4 lis 2022, 15:26 użytkownik Ilija Tovilo napisał: > Hi everyone > > I'd like to propose a simple RFC to introduce looking up class > constants by name. We have dedicated syntax for basically all other > language constructs. This RFC aims to get rid of this seemingly > arbitrary limitation. > > https://wiki.php.net/rfc/dynamic_class_constant_fetch Can it be extended to non class constants and additionally deprecations plan for constant() function? I know it may not be the easiest but if we are about completeness and consistency I think coins the cleanup with planned standard library function removal would be complete. Cheers, Michał Marcin Brzuchalski
Re: [PHP-DEV] [RFC][Dynamic class constant fetch]
On Fri, Nov 4, 2022 at 12:08 PM someniatko wrote:
> > What's convenient about `Foo::{$bar}` vs `constant(Foo::class . '::' .
> > $bar)`? I'm a bit confused by this :|
> >
> > Is it the few keystrokes added?
>
> Even if ignoring syntax / convenience bikeshedding, I find it a really
> valuable addition to the language self-consistency. It's symmetrical
> to the already existing syntax of dynamic property fetch and dynamic
> method calls. One could argue that it's dynamic, too much magic and
> bad, but then we should either deprecate those features, or if not,
> have this symmetry. The Principle of Least Amusement and human pattern
> recognition overall with thank you.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
I agree with @someniatko, it makes PHP more consistent, which IMHO
is always positive and one of the usually criticized points (lack of
consistency
throughout parameter order, naming convention etc).
Re: [PHP-DEV] [RFC][Dynamic class constant fetch]
> What's convenient about `Foo::{$bar}` vs `constant(Foo::class . '::' .
> $bar)`? I'm a bit confused by this :|
>
> Is it the few keystrokes added?
Even if ignoring syntax / convenience bikeshedding, I find it a really
valuable addition to the language self-consistency. It's symmetrical
to the already existing syntax of dynamic property fetch and dynamic
method calls. One could argue that it's dynamic, too much magic and
bad, but then we should either deprecate those features, or if not,
have this symmetry. The Principle of Least Amusement and human pattern
recognition overall with thank you.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Dynamic class constant fetch]
On Fri, Nov 4, 2022, at 9:45 AM, Ralf Lang wrote:
> Hi Ilija,
>
> Am 04.11.2022 um 15:25 schrieb Ilija Tovilo:
>> Please let me know if you have any thoughts.
>>
>> Ilija
>
> That new way of accessing class constants dynamically does not really
> make things more readable for me. Maybe I just need to get used to it,
> but especially that last example would make my head spin without
> additional comments:
>
> Foo::{test('foo')}::{test('bar')}; Maybe I miss the use case. What kind
> of code would benefit
> from this? Wouldn't just using constant() for dynamically built
> constant
> strings be more legible? Maybe in a separate line? In the past I used a
> lot of flag constants backed by integers. A lot of these use cases have
> become classes/types in their own right since. When do you use these
> constants? Just my thoughts.
Dynamically building strings for syntax is almost never more legible. :-) I
doubt you'd ever double them up the way some of the examples show.
In practice, the single Class::{$const} or Enum::{$name} would be the most
common uses, I predict, and those are way nicer to read than the 3x longer
constant() with string concat.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] ARRAY_UNIQUE_IDENTICAL option
On 04.11.2022 at 10:05, Rowan Tommins wrote: > On 3 November 2022 18:53:40 GMT, someniatko wrote: > >> You will have to memorize yet another PHP quirk, or be able to build a >> logical chain: >> - enums are non-comparable by default >> - enums have no default string value (if not baked by a string) >> - array_unique internally sorts an array >> - default flag for array_unique compares the string representations of its >> items >> - thus it won't work for enums in a general case > > Actually, I think this is already the case for "normal" objects - I had no > idea that array_unique used a string cast to compare objects, so am very > surprised that it will not consider objects of completely different classes > unique, if they happen to have the same string value: https://3v4l.org/UGCvB > > Making backed enums work with their backing value would be equally confusing > to me - Day::MONDAY and Month::JANUARY might both be backed by a 1, but they > are certainly distinct values. I'd much rather get an error that made me > check the manual and find a flag than have one of them silently discarded. I agree. In my opinion, we should *consider* to *always* raise a warning on attempts to compare incomparable values. As it is now, silently returning false looks like a footgun to me. -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Dynamic class constant fetch]
On Fri, 4 Nov 2022 at 15:40, Larry Garfield wrote:
> On Fri, Nov 4, 2022, at 9:31 AM, Marco Pivetta wrote:
> > Heyo,
> >
> > On Fri, 4 Nov 2022 at 15:26, Ilija Tovilo
> wrote:
> >
> >> Hi everyone
> >>
> >> I'd like to propose a simple RFC to introduce looking up class
> >> constants by name. We have dedicated syntax for basically all other
> >> language constructs. This RFC aims to get rid of this seemingly
> >> arbitrary limitation.
> >>
> >> https://wiki.php.net/rfc/dynamic_class_constant_fetch
> >>
> >> Please let me know if you have any thoughts.
> >>
> >
> > What's the problem with using `constant()` for this?
> >
> > Marco Pivetta
> >
> > https://twitter.com/Ocramius
> >
> > https://ocramius.github.io/
>
> As it says right in the RFC:
>
> // This:
> echo Foo::{$bar};
>
> // is way more convenient than this mess:
> echo constant(Foo::class . '::' . $bar);
>
> This is something people have mentioned a number of times with enums and
> dynamic case references, and seems like a good small cleanup.
>
What's convenient about `Foo::{$bar}` vs `constant(Foo::class . '::' .
$bar)`? I'm a bit confused by this :|
Is it the few keystrokes added?
Marco Pivetta
https://twitter.com/Ocramius
https://ocramius.github.io/
Re: [PHP-DEV] [RFC][Dynamic class constant fetch]
Hi Ilija,
Am 04.11.2022 um 15:25 schrieb Ilija Tovilo:
Please let me know if you have any thoughts.
Ilija
That new way of accessing class constants dynamically does not really
make things more readable for me. Maybe I just need to get used to it,
but especially that last example would make my head spin without
additional comments:
Foo::{test('foo')}::{test('bar')}; Maybe I miss the use case. What kind of code would benefit
from this? Wouldn't just using constant() for dynamically built constant
strings be more legible? Maybe in a separate line? In the past I used a
lot of flag constants backed by integers. A lot of these use cases have
become classes/types in their own right since. When do you use these
constants? Just my thoughts.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Dynamic class constant fetch]
On Fri, Nov 4, 2022, at 9:31 AM, Marco Pivetta wrote:
> Heyo,
>
> On Fri, 4 Nov 2022 at 15:26, Ilija Tovilo wrote:
>
>> Hi everyone
>>
>> I'd like to propose a simple RFC to introduce looking up class
>> constants by name. We have dedicated syntax for basically all other
>> language constructs. This RFC aims to get rid of this seemingly
>> arbitrary limitation.
>>
>> https://wiki.php.net/rfc/dynamic_class_constant_fetch
>>
>> Please let me know if you have any thoughts.
>>
>
> What's the problem with using `constant()` for this?
>
> Marco Pivetta
>
> https://twitter.com/Ocramius
>
> https://ocramius.github.io/
As it says right in the RFC:
// This:
echo Foo::{$bar};
// is way more convenient than this mess:
echo constant(Foo::class . '::' . $bar);
This is something people have mentioned a number of times with enums and
dynamic case references, and seems like a good small cleanup.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Dynamic class constant fetch]
Heyo, On Fri, 4 Nov 2022 at 15:26, Ilija Tovilo wrote: > Hi everyone > > I'd like to propose a simple RFC to introduce looking up class > constants by name. We have dedicated syntax for basically all other > language constructs. This RFC aims to get rid of this seemingly > arbitrary limitation. > > https://wiki.php.net/rfc/dynamic_class_constant_fetch > > Please let me know if you have any thoughts. > What's the problem with using `constant()` for this? Marco Pivetta https://twitter.com/Ocramius https://ocramius.github.io/
[PHP-DEV] [RFC][Dynamic class constant fetch]
Hi everyone I'd like to propose a simple RFC to introduce looking up class constants by name. We have dedicated syntax for basically all other language constructs. This RFC aims to get rid of this seemingly arbitrary limitation. https://wiki.php.net/rfc/dynamic_class_constant_fetch Please let me know if you have any thoughts. Ilija -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] ARRAY_UNIQUE_IDENTICAL option
On 3 November 2022 18:53:40 GMT, someniatko wrote: >You will have to memorize yet another PHP quirk, or be able to build a >logical chain: >- enums are non-comparable by default >- enums have no default string value (if not baked by a string) >- array_unique internally sorts an array >- default flag for array_unique compares the string representations of its >items >- thus it won't work for enums in a general case Actually, I think this is already the case for "normal" objects - I had no idea that array_unique used a string cast to compare objects, so am very surprised that it will not consider objects of completely different classes unique, if they happen to have the same string value: https://3v4l.org/UGCvB Making backed enums work with their backing value would be equally confusing to me - Day::MONDAY and Month::JANUARY might both be backed by a 1, but they are certainly distinct values. I'd much rather get an error that made me check the manual and find a flag than have one of them silently discarded. Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
