Re: [PHP-DEV] [RFC] Property hooks, nee accessors
On Tue, May 9, 2023 at 4:38 AM Larry Garfield wrote:
>
> Ilija Tovilo and I would like to offer another RFC for your consideration.
> It's been a while in coming, and we've evolved the design quite a bit just in
> the last week so if you saw an earlier draft of it in the past few months, I
> would encourage you to read it over again to make sure we're all on the same
> page. I'm actually pretty happy with where it ended up, even if it's not the
> original design. This approach eliminates several hard-to-implement edge
> cases while still providing a lot of functionality in one package.
>
> https://wiki.php.net/rfc/property-hooks
>
> --
> Larry Garfield
> la...@garfieldtech.com
Hi, Larry
```
interface IFace
{
public string $readable { get; }
public string $writeable { set; }
public string $both { get; set; }
}
```
How important is ```{ get; }``` statement (and friends) in the interface?
Since PHP does not enforce method definition existence in caller site,
this code is valid (at least at compile time):
```
interface IA {
// ...
}
interface IB {
public function doIt(IA $par1);
}
class CA1 implements IA {
// makeIt is not part of IA
public function makeIt() {
echo " makeIt() is called";
}
}
class CA2 implements IA {}
class CB implements IB {
public function doit(IA $par1) {
// makeIt is not enforced to be invalid
$par1->makeit();
}
}
$a1 = new CA1;
$a2 = new CA2;
$b = new CB;
$b->doIt($a1); // valid
$b->doIt($a2); // invalid at runtime
```
IMO, ```{ get; }``` (and friends) only useful if there are:
* definition existence enforcement or implemented asymmetric visibility
* AND no default hook implementation provided.
I assume that ```{ get; }``` do exist in the property accessors
proposal because there is no default hook implementation. Whether
there is already implemented property definition existence enforcement
or not, i don't know. If yes, then all things are in the right place.
If not, it feels like a half baked feature, just like the method was:
the error will pop up at runtime. The only positive value is ```{ get;
}``` can still be consumed by static analysis tools.
```
class CX {
public function consumeIt(IFace $par) {
// this statement should trigger error
// produced by engine or SA tools
$par->readable = "hello";
}
}
```
Things will be different with property hooks. Without definition
existence enforcement nor implemented asymmetric visibility, static
analysis tools will give misconception about unlisted hooks if there
is error/warning message.
```
class CX {
public function consumeIt(IFace $par) {
// default hook is provided by engine
// any message is not relevant for this valid statement
$par->readable = "hello";
}
}
```
If there is no forward compatibility consideration, can we simplify
interface definition to this one?
```
interface IFace
{
public string $readable;
public string $writeable;
public string $both;
}
```
Thanks in advance.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property hooks, nee accessors
On Tue, May 9, 2023 at 4:38 AM Larry Garfield wrote:
>
> Ilija Tovilo and I would like to offer another RFC for your consideration.
> It's been a while in coming, and we've evolved the design quite a bit just in
> the last week so if you saw an earlier draft of it in the past few months, I
> would encourage you to read it over again to make sure we're all on the same
> page. I'm actually pretty happy with where it ended up, even if it's not the
> original design. This approach eliminates several hard-to-implement edge
> cases while still providing a lot of functionality in one package.
>
> https://wiki.php.net/rfc/property-hooks
>
> --
> Larry Garfield
> la...@garfieldtech.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
Hi Larry.
Suppose that I just want to cache once and freeze, and I don't want to
create additional hidden property. Please make a judgement on the
validity of this syntax:
```
public string $prop1 {
get => $field ??= $this->heavyTask($this->propx, $prop->y);
set => null;
}
```
Explanation:
* Since the ```get``` hook uses ```$field```, the engine will create a
backing store value with name ```$prop1```, and will be filled at the
first call only. The later call will use the already stored value.
* Since no new value is assigned to ```$field``` in the ```set```
hook, the value stored in ```$prop1``` is still the same as before.
* Since any return statement will be discharged in ```set``` hook, the
assignment chaining is safe to use and the value which is transferred
is alway the rightmost value (not the value returned by the ```set```
hook).
```
$varx = $obj->prop1 = "hello"; // $varx value is "hello", and
$obj->prop1 value is unchanged
```
But, this statement below is NOT ALWAYS correct for "cache once and freeze":
```
public string $prop1 {
set => $field ??= $this->heavyTask($this->propx, $prop->y);
}
```
Explanation:
* Since default ```get``` hook can be called before ```set``` hook,
backing store value with name ```$prop1``` will still be empty.
* Otherwise, I have to duplicate the body of the ```set``` hook into
```get``` hook to prevent an emptiness backing store.
Please give a comment.
Thanks.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property hooks, nee accessors
On Tue, May 9, 2023 at 4:38 AM Larry Garfield wrote:
>
> Ilija Tovilo and I would like to offer another RFC for your consideration.
> It's been a while in coming, and we've evolved the design quite a bit just in
> the last week so if you saw an earlier draft of it in the past few months, I
> would encourage you to read it over again to make sure we're all on the same
> page. I'm actually pretty happy with where it ended up, even if it's not the
> original design. This approach eliminates several hard-to-implement edge
> cases while still providing a lot of functionality in one package.
>
> https://wiki.php.net/rfc/property-hooks
>
> --
> Larry Garfield
> la...@garfieldtech.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
Hi Larry.
```
public string $fullName => $this->first . " " . $this->last;
```
1. Suppose that I forgot to declare ```$this->first```. Based on the
"deprecate dynamic properties" proposal, will I get an error/warning?
2. The shorthand notations supported (the shortest one) creates
impaired syntax, and not pretty to look at for constructor property
promotion.
```
public function __construct(
public string $prop1 => strtoupper($this->_prop1),
public string $prop2 {set => $field = strtolower($value);},
){}
```
My suggestion is: use get/set keyword immediately after property
name/default value rather than "=>" or "{" without losing multiline
statements.
```
public function __construct(
public string $prop1 get => strtoupper($this->_prop1),
public string $prop2 set => $field = strtolower($value),
public string $prop3 get {
$temp = strtoupper($this->_prop1);
return substr($temp, 0, 10) . '...';
}
public string $prop4 set {
$temp = strtolower($value);
$field = substr($temp, 0, 10);
}
){}
```
This syntax is aligned with a single statement if/for/foreach.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Please remove the Sicherheitsüberprüfung Security captcha from php.net
On Sun, 14 May 2023 at 22:59, Hans Henrik Bergan wrote: > > I'm not sure there is an English version at all For me, there is an English version below the German version, Er, and apparently for you also: https://phpimagick.com/deutsche_uber_englisch_2.png > my Accept-Language doesn't mention German, and it > specifically requests English, My guess, content negotiation is a really low priority for a DOS protection service. > it specifically requests English, and I'm not accessing the german > de.php.net, so if an English version existed, there would be no reason > for it to give me a German version, Englisch ist nicht die Standardeinstellung. For a German company, providing services to German speaking countries, putting the German version above the English version seems a reasonable reason. I believe Derick has sent an email message to noc@ and systems@, so hopefully something will be adjusted. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Please remove the Sicherheitsüberprüfung Security captcha from php.net
>a misconfiguration
That's my guess too.
I Hope the server configuration people get the message.
>I think the page is just hard-coded in German and English
I'm not sure there is an English version at all - I'm not accessing it
from a german IP address (a Norwegain one - actually multiple
Norwegian ones), and my Accept-Language doesn't mention German, and it
specifically requests English, and I'm not accessing the german
de.php.net, so if an English version existed, there would be no reason
for it to give me a German version, so my best guess is that it's just
hardcoded in German.
(tl;dr: if an English version exists, I have no idea why I was served
the German version.)
On Sun, 14 May 2023 at 23:36, Rowan Tommins wrote:
>
> On 14 May 2023 21:48:51 BST, Hans Henrik Bergan wrote:
> >fwiw for those of you lucky enough to not get the captcha page, it
> >looks like https://i.imgur.com/l9YbIz5.png
>
> I'd never seen it before, but saw it just now when looking for mirror
> information. My guess is that either there's a misconfiguration somewhere
> making it far too sensitive, or there's something like a DoS attack being
> defended against.
>
>
> >Also I'm not sure why it's in German
>
> I think the page is just hard-coded in German and English because the company
> hosting the mirror ("MyraCloud") are based in Germany, and haven't added any
> other translations.
>
>
> Regards,
>
> --
> Rowan Tommins
> [IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Please remove the Sicherheitsüberprüfung Security captcha from php.net
On 14 May 2023 21:48:51 BST, Hans Henrik Bergan wrote:
>fwiw for those of you lucky enough to not get the captcha page, it
>looks like https://i.imgur.com/l9YbIz5.png
I'd never seen it before, but saw it just now when looking for mirror
information. My guess is that either there's a misconfiguration somewhere
making it far too sensitive, or there's something like a DoS attack being
defended against.
>Also I'm not sure why it's in German
I think the page is just hard-coded in German and English because the company
hosting the mirror ("MyraCloud") are based in Germany, and haven't added any
other translations.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Please remove the Sicherheitsüberprüfung Security captcha from php.net
multiple times per week now, i get this Security Sicherheitsüberprüfung captcha page when visiting php.net and it's really annoying to solve that captcha multiple times per week. "PHP is that annoying language where you have to solve captchas just to read the documentation" is not the experience we want to give users, and as ChatGPT puts it >>lead to negative perceptions of PHP as a language, as well as decreased >>productivity among developers who would have to spend extra time overcoming >>the verification obstacles to access the documentation. It would also make it >>more difficult for new developers to learn PHP, which could ultimately have a >>negative impact on the growth and adoption of the language fwiw for those of you lucky enough to not get the captcha page, it looks like https://i.imgur.com/l9YbIz5.png Also I'm not sure why its in German - i dont speak German, and my Accept-Lanaguage header says Accept-Language: en-US,en;q=0.9,nb;q=0.8,no;q=0.7,vi;q=0.6 (where en-US is English, and nb is Norwegian Bokmål, and no is Norwegain, and vi is Vietnamese. German isn't even on the accept-language list!) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Discussion] nameof
> Conversely, namespace imports are entirely local to the current file (or even
> a namespace{} block), and it's almost impossible for running code to see
> anything other than the expanded name.
>
> That doesn't mean that there aren't good reasons to have nameof() handle both
> things in the way proposed, I just think those reasons are probably different
> for the two cases.
That's a fair point. Maybe it is worth putting it up for a secondary
vote? I do have a strong preference, but I'd rather have full names
than no names, and doesn't change the RFC that much. If I'm
understanding correctly, it would only affect first-class callables
and constants.
> >> Can you give an example of such an error message that would want to expose
> >> the local alias?
> >
> >Which error message helps in resolving the error and would be written
> >by someone writing the code?
>
> To clear up any doubt, there was no sarcasm or aggression intended, I was
> genuinely requesting an example, which you have provided, so thank you.
FWIW, I didn't see it as a sarcastic question, but I'm a very
sarcastic person IRL... so maybe I did and I just ignored it. ¯\_
()_/¯ Either way, it was a good question.
> This seems to be a common sentiment indeed - people prefer long lists of "use
> function" to \ prefixes. It's not something I personally find unnatural, any
> more than "/images/logo.png" or "/etc/hosts", but I'm willing to concede I
> may be in a minority there.
I've seen hundreds of lines of nothing but `use`... it's terrifying
once you end up with a smattering of aliases thrown in, randomly, for
good measure. I don't think you're in the minority for people who've
been using PHP a long time -- or bitten by those files. As someone
who's had to wade through those codebases, aliases matter a lot and
I'd like to see them respected. I'm also realizing, as this discussion
goes on, that there is precedent for the expansion via ::class, so
maybe that is the right way to go after all? 樂
> The biggest weakness of a generic "nameof" is that it still doesn't hint what
> kind of thing you want to mention.
The 'kind' of the thing doesn't really matter, we just want the name
of the thing. Basically, the string before `(...)`; the string after
`->`,`::`, `$`, or in the case of constants, the string itself.
> >IMHO, this comment isn't constructive or helpful, how can I help you
> >understand? I'm more than happy to answer any and all questions, but
> >comments like this are pretty demoralizing when there are only a few
> >people discussing the feature in a community I'm relatively new to
>
> I'm genuinely sorry you felt this way, and it was absolutely not my intention
> to criticise you. If anything, it was meant to be an admission of my own
> failings, that I'd come into the discussion with the wrong preconceptions,
> because the use cases which immediately came into my head seemed to have
> contrasting requirements from the ones that you intended.
Thanks for explaining your intentions and no hard feelings from me. It
can feel like an 'island of one' putting an RFC forward for the first
time and a bit daunting when receiving negative feedback.
Maybe there should be a 'buddy system' for first-time submissions that
reach the discussion phase? A more experienced contributor could
volunteer to help guide the person through the process, answer weird
questions (like when is a secondary vote required or useful? I got
some feedback that it was a bad idea to include one, but why? I'm sure
there's some background there, but I'm in the dark with nobody to
reach out to and ask for history lessons), give informal feedback, and
someone to reach out to when you get stuck.
> To put things into a more productive context, then, I think a useful
> improvement to the RFC would be some examples of how you would use it with
> the different supported types, showing why the proposed semantics are useful
> for those scenarios.
I can do that for sure.
> On a different note, you've talked about how errors would be handled for
> nonexistent constructs, but given PHP's dynamic nature, there's also a
> question of *when* they would need to exist. For instance, assuming we go
> with Warnings, if I use nameof(Foo::bar), and class Foo is defined in a
> different file, there's a few things that could happen:
>
> - the resolution happens while compiling a single file, in which case it will
> always give a Warning, because any symbol outside the file is unknown
> - the resolution happens at runtime, and causes class Foo to be autoloaded
> - the resolution happens at runtime but doesn't trigger autoloading, so
> whether it gives a Warning or not depends on whether other code happens to
> have loaded the definition of Foo
> - probably other options that I haven't considered
>
> With the "no error handling" version, this becomes moot, because it's just a
> string manipulation exercise. That's how ::class currently works, apart from
> a few specific
Re: [PHP-DEV] [RFC] [Discussion] nameof
On 14 May 2023 11:59:13 BST, Robert Landers wrote:
>As someone who has had limited interaction with the engine code itself
>but has been using PHP, daily, for nearly 15 years, I'm not sure this
>technical distinction makes sense in the context of programming in
>PHP. When using traits, I don't think of it as 'inserting code', but
>rather I think of it as 'using code' -- you do use `use TraitName`
>after all and it is very similar to the top-level using statement.
I don't think it's a technical distinction at all, it's part of the definition
of traits in PHP, which are often described as "compiler assisted copy and
paste". The methods from the trait are added to the definition of the class
during compilation, and after that it is almost impossible to distinguish them
from methods written directly in the class definition.
Conversely, namespace imports are entirely local to the current file (or even a
namespace{} block), and it's almost impossible for running code to see anything
other than the expanded name.
That doesn't mean that there aren't good reasons to have nameof() handle both
things in the way proposed, I just think those reasons are probably different
for the two cases.
>> Can you give an example of such an error message that would want to expose
>> the local alias?
>
>Which error message helps in resolving the error and would be written
>by someone writing the code?
To clear up any doubt, there was no sarcasm or aggression intended, I was
genuinely requesting an example, which you have provided, so thank you.
>use function \Path\To\Function\Serializer\to_json as json_serializer;
>
>// a bunch of code using json_serializer()
>throw new Exception('json_serializer returned invalid json');
>// or
>throw new Exception('\Path\To\Function\Serializer\to_json returned
>invalid json');
I can see your reasoning now, but I can think of arguments both ways round: if
you're trying to find out *why* the function returned invalid JSON, you need to
know where the source code for that function is, so need its fully qualified
name.
My gut feel is still that it's more often useful to have the expansion done for
you, but maybe others have different perspectives.
>This would also be weird in the case of constants/functions in the
>global space, because fully qualified names begin with a "\" which
>feels unnatural when reading things meant for humans (such as error
>messages).
This seems to be a common sentiment indeed - people prefer long lists of "use
function" to \ prefixes. It's not something I personally find unnatural, any
more than "/images/logo.png" or "/etc/hosts", but I'm willing to concede I may
be in a minority there.
>> Not really, I'm afraid. If I have to write out the fully-qualified name, why
>> would I bother with nameof() rather than just using a string?
>
>If you write it in a string you really will, actually, have to write
>out the fully qualified name because an IDE won't know you're
>referencing a language construct and be able to autocomplete it for
>you. If you rename the function or remove it, you won't be able to use
>static analysis to locate these strings, you'll have to manually
>search-and-replace the codebase, which opens up space for human error.
This makes some sense, although static analysis tools and IDEs already do a lot
with pseudo-types in docblocks to understand the expected values of strings.
The biggest weakness of a generic "nameof" is that it still doesn't hint what
kind of thing you want to mention.
>IMHO, this comment isn't constructive or helpful, how can I help you
>understand? I'm more than happy to answer any and all questions, but
>comments like this are pretty demoralizing when there are only a few
>people discussing the feature in a community I'm relatively new to
I'm genuinely sorry you felt this way, and it was absolutely not my intention
to criticise you. If anything, it was meant to be an admission of my own
failings, that I'd come into the discussion with the wrong preconceptions,
because the use cases which immediately came into my head seemed to have
contrasting requirements from the ones that you intended.
To put things into a more productive context, then, I think a useful
improvement to the RFC would be some examples of how you would use it with the
different supported types, showing why the proposed semantics are useful for
those scenarios.
On a different note, you've talked about how errors would be handled for
nonexistent constructs, but given PHP's dynamic nature, there's also a question
of *when* they would need to exist. For instance, assuming we go with Warnings,
if I use nameof(Foo::bar), and class Foo is defined in a different file,
there's a few things that could happen:
- the resolution happens while compiling a single file, in which case it will
always give a Warning, because any symbol outside the file is unknown
- the resolution happens at runtime, and causes class Foo to be autoloaded
Re: [PHP-DEV] [RFC] [Discussion] nameof
On Sun, May 14, 2023 at 11:16 AM Rowan Tommins wrote:
>
> On 13 May 2023 16:40:27 BST, Robert Landers wrote:
> > Most of the time, you want the unqualified name
> > ...
> >This is especially important when using traits and aliases:
>
> I don't think trait renaming is the same thing as aliasing a qualified name.
> In a sense, it's actually the opposite: with a trait, the compiler is
> inserting the code of the method under the new name, and the name from the
> trait can no longer be used to access it; for namespace imports, the compiler
> is substituting the fully-qualified name, and the *local alias* can no longer
> be used to access it.
As someone who has had limited interaction with the engine code itself
but has been using PHP, daily, for nearly 15 years, I'm not sure this
technical distinction makes sense in the context of programming in
PHP. When using traits, I don't think of it as 'inserting code', but
rather I think of it as 'using code' -- you do use `use TraitName`
after all and it is very similar to the top-level using statement.
> >In this case, if you want to use nameof(TEST) in an error message or
> >something else, it would be surprising to get \A\A instead of TEST.
>
> Would it? As I said before, my intuition was completely the opposite, that
> one of the advantages of writing nameof(TEST) rather than just 'TEST' is that
> it would resolve namespace imports the same way ::class does.
>
> Can you give an example of such an error message that would want to expose
> the local alias?
Which error message helps in resolving the error and would be written
by someone writing the code?
use function \Path\To\Function\Serializer\to_json as json_serializer;
// a bunch of code using json_serializer()
throw new Exception('json_serializer returned invalid json');
// or
throw new Exception('\Path\To\Function\Serializer\to_json returned
invalid json');
The former appears more natural and helps to trace the issue.
Otherwise, you end up in the file, trying to dig through usings to
figure out where usages of \Path\To\Function\Serializer\to_json are in
the file because, at first glance, it appears to not be there.
This would also be weird in the case of constants/functions in the
global space, because fully qualified names begin with a "\" which
feels unnatural when reading things meant for humans (such as error
messages).
> >So, for your example, we can instead call nameof(\Acme\bar(...))
> >instead of the aliased name when passing to another context:
> >
> >use function Acme\bar as foo;
> >...
> >#[SomeAttribute(callback: nameof(\Acme\bar(...))]
> >...
> >
> >I hope this helps!
>
>
> Not really, I'm afraid. If I have to write out the fully-qualified name, why
> would I bother with nameof() rather than just using a string?
If you write it in a string you really will, actually, have to write
out the fully qualified name because an IDE won't know you're
referencing a language construct and be able to autocomplete it for
you. If you rename the function or remove it, you won't be able to use
static analysis to locate these strings, you'll have to manually
search-and-replace the codebase, which opens up space for human error.
nameof() gives you a fighting chance of actually finding ALL the
usages in one go.
Personally, I've found that refactoring the names of things in PHP is
one of the most dangerous coding activities one can do in PHP. They
may be in a string, a database, on the wire via `serialize(),` or any
number of places. Making this a safer activity is one of my personal
goals.
> The more I read in this thread, the less I understand what the point of
> nameof() actually is, and how it would be used.
IMHO, this comment isn't constructive or helpful, how can I help you
understand? I'm more than happy to answer any and all questions, but
comments like this are pretty demoralizing when there are only a few
people discussing the feature in a community I'm relatively new to --
are my answers not clear enough, would a call help, or should I
reference other language's implementations and rationales? I don't
know the unwritten rules here, and being helpful and constructive can
move the conversation forward instead of reaching impasses.
Personally, I've been in war and dealt with far worse than this, but
someone who hasn't been through what I've been through may not be as
"thick-skinned" and just walk away. Just something to keep in mind for
future interactions.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Discussion] nameof
On 13 May 2023 16:40:27 BST, Robert Landers wrote: > Most of the time, you want the unqualified name > ... >This is especially important when using traits and aliases: I don't think trait renaming is the same thing as aliasing a qualified name. In a sense, it's actually the opposite: with a trait, the compiler is inserting the code of the method under the new name, and the name from the trait can no longer be used to access it; for namespace imports, the compiler is substituting the fully-qualified name, and the *local alias* can no longer be used to access it. The "real" name of a method copied in from a trait is whatever it's called in the target class, but the "real" name of a function aliased with "use function ... as ..." is undoubtedly its fully-qualified name. >In this case, if you want to use nameof(TEST) in an error message or >something else, it would be surprising to get \A\A instead of TEST. Would it? As I said before, my intuition was completely the opposite, that one of the advantages of writing nameof(TEST) rather than just 'TEST' is that it would resolve namespace imports the same way ::class does. Can you give an example of such an error message that would want to expose the local alias? >So, for your example, we can instead call nameof(\Acme\bar(...)) >instead of the aliased name when passing to another context: > >use function Acme\bar as foo; >... >#[SomeAttribute(callback: nameof(\Acme\bar(...))] >... > >I hope this helps! Not really, I'm afraid. If I have to write out the fully-qualified name, why would I bother with nameof() rather than just using a string? The more I read in this thread, the less I understand what the point of nameof() actually is, and how it would be used. Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
