Re: [PHP-DEV][RFC] Rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
On Wed, Jun 10, 2020 at 3:14 PM Sara Golemon wrote: > On Wed, Jun 10, 2020 at 3:33 PM Ryan Jentzsch > wrote: > > > OMG the trolling continues even today with this nonsense. Disappointing. > > > > Oh yes. And histrionics will certainly deescalate that issue. > > > > "...yes, it is broken, people have to Google or ask around for a very > > unclear error message when for the most part errors are (and should be) > > self explanatory > > > > You know what shows up unambiguously in a google search? "Paamayim > Nekudotayim". > You know what ISN'T unambiguous in a google search? "Double Colon" > You know who don't have an excuse to say "Google is hard"? Software > engineers. > > > Can I say Double Thumbs Up to the comment about Google searches? Anybody doing software development without using a search engine is typing with one hand. When making requests, stop inventing bad ideas. Do you actually know developers that write software without ever using a search engine to look up errors? Given how most docs have moved online, that seems like people doing things the hard way without good reason. Assuming you have actually met these people, who have not even bothered to even learn the basics of life in the modern age, why must we change to support them? Couldn't we just put a line in some doc somewhere about how using search engines is a vital piece of development technology somewhere between using print statements and how to use a debugger? > > ...Two things are broken: Either the token is named badly, or the token > > names shouldn’t show up in error messages at all and be replaced with > > something a bit more friendly. > > > > Token names shouldn't show up. Everyone is agreeing with that statement. > Universally. Let's fix that problem rather than create new ones by not > addressing the underlying issue. > > Once again I plead for logic and sanity. At least have the courage to put > > it to a vote. > > > > Absolutely. Put it to a vote. I've got my "no" all locked and loaded. > > -Sara > -- The greatest dangers to liberty lurk in insidious encroachment by men of zeal, well-meaning but without understanding. -- Justice Louis D. Brandeis
Re: [PHP-DEV][RFC] Rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
On Wed, Jun 10, 2020 at 3:33 PM Ryan Jentzsch wrote: > OMG the trolling continues even today with this nonsense. Disappointing. > Oh yes. And histrionics will certainly deescalate that issue. > "...yes, it is broken, people have to Google or ask around for a very > unclear error message when for the most part errors are (and should be) > self explanatory > You know what shows up unambiguously in a google search? "Paamayim Nekudotayim". You know what ISN'T unambiguous in a google search? "Double Colon" You know who don't have an excuse to say "Google is hard"? Software engineers. > ...Two things are broken: Either the token is named badly, or the token > names shouldn’t show up in error messages at all and be replaced with > something a bit more friendly. > Token names shouldn't show up. Everyone is agreeing with that statement. Universally. Let's fix that problem rather than create new ones by not addressing the underlying issue. Once again I plead for logic and sanity. At least have the courage to put > it to a vote. > > Absolutely. Put it to a vote. I've got my "no" all locked and loaded. -Sara
Re: [PHP-DEV][RFC] Rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
On 10/06/2020 19:28, Claude Pache wrote: One parsing error that I still find dreadful after more than 10 years of PHP coding, is: unexpected T_CONSTANT_ENCAPSED_STRING. Although T_CONSTANT_ENCAPSED_STRING is like Hebrew for me, I’ve learned with time that when I get such an error, it means that I’ve most probably omitted or mistyped some punctuation mark somewhere. I think this is a really good point, and I would like to expand on it: rather than renaming T_PAAMAYIM_NEKUDOTAYIM, we should simply ensure the user never needs to see it. A long time ago, PHP's parser errors were extremely cryptic, e.g. "::" would tell you: > Parse error: syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM Since PHP 5.4 (according to https://3v4l.org/Hdjk8) the error message includes the actual token encountered: > Parse error: syntax error, unexpected '::' (T_PAAMAYIM_NEKUDOTAYIM) If I understand correctly, the current proposal will instead give us this: > Parse error: syntax error, unexpected '::' (T_DOUBLE_COLON) But why not simply this: > Parse error: syntax error, unexpected '::' Imagine you are a new PHP developer, who has only the vaguest idea of what "parse" means; along with '::' (T_PAAMAYIM_NEKUDOTAYIM) you may encounter such mysteries as these: '<<' (T_SL) '>>' (T_SR) __NAMESPACE__ (T_NS_C) ''foo'' (T_CONSTANT_ENCAPSED_STRING) [which is a string, not a constant] 'foo' (T_STRING) [which is definitely not a string, but might be a constant] ... (T_ELLIPSIS) [a lot of people will misread this as "ellipse", a much more common word] ** (T_POW) [is that the Star Trek character, or the rock band named after her?] Even straight-forward names like '==' (T_IS_EQUAL) are confusing - for years I wondered what that "T_" meant, my experience with Delphi making me guess at "type", which didn't make much sense. I can see a small advantage of including something that is easy to search for; but how often does the solution to a parse error depend on exactly what the unexpected token was, so that searching for "Parse error: syntax error, unexpected" wouldn't give enough of a hint? Other information currently missing from the message - e.g. column number, hints about unclosed blocks - is likely to be far more useful. Regards, -- Rowan Tommins (né Collins) [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV][RFC] Rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
On Wed, Jun 10, 2020 at 4:33 PM Ryan Jentzsch wrote: > OMG the trolling continues even today with this nonsense. Disappointing. > Calling T_PAAMAYIM_NEKUDOTAYIM a non-issue is simply wrong and here's why:: > "People don’t ask for the other parse errors even half as often as they as > for T_PAAMAYIM_NEKUDOTAYIM They do so because it looks like gibberish to > them, so it looks unlikely to be a common thing you can Google, nor it > gives something recognizable to start with [sic] Yes, we all acknowledge > it’s an easter egg joke that refers to the creators of PHP. But that > particular joke has outworn its welcome in the community after repeatedly > CAUSING SUPPORT ISSUES." -Stan Vass (emphasis mine) > > I agree that it isn't the biggest issue in the world. If we had to give up one of the more impactful changes in order to implement this, it would be a different story. But that's not the case. There is no trade off here. The RFC even contains the updates required, so it's not going to take up anyone's time that could be spent on other features. > "It's a minor change and an annoyance to a lot of people. Yes, by not > changing this you’re annoying thousands of people." -Alexander Schrijver > > "It’s the same argument everyone else is giving, and really it all comes > down to this.: > Nostalgia is valued over clarity and consistency. Do you guys REALLY want > to claim that?" -Chad Minick > > "...yes, it is broken, people have to Google or ask around for a very > unclear error message when for the most part errors are (and should be) > self explanatory > ...Two things are broken: Either the token is named badly, or the token > names shouldn’t show up in error messages at all and be replaced with > something a bit more friendly. > ...What is so hard to believe when people see UNEXPECTED T_DOUBLE_COLON on > LINE 23 they are gonna look for a double colon on line 23?" -Chad Minick > > Honestly, I'm not a big fan of the following argument: "However, PHP is for most people their first programming language and therefore may not have the instinct to do an online search and will end up frustrated." - Googling is such a core skill for programming, that if they can't figure that out, they don't need to be programming. However, that being said, I don't think that argument is even needed to justify this RFC anyway. The only place this MIGHT cause an issue is unit tests that are looking for that specific string. While I'm not a fan of the "just use find/replace" to update things argument, I think that's a perfectly valid one here, given the uniqueness of the string being changed. > Once again I plead for logic and sanity. At least have the courage to put > it to a vote. > > On Wed, Jun 10, 2020, 12:28 PM Claude Pache > wrote: > > > Hi, > > > > I appreciate the effort to reduce frustration in PHP coding. > > > > However, T_PAAMAYIM_NEKUDOTAYIM is a non-issue: you learn it once and > > you’re done for the rest of your life. > > > > May I suggest an improvement that would be much more useful than renaming > > tokens? > > > > One parsing error that I still find dreadful after more than 10 years of > > PHP coding, is: unexpected T_CONSTANT_ENCAPSED_STRING. Although > > T_CONSTANT_ENCAPSED_STRING is like Hebrew for me, I’ve learned with time > > that when I get such an error, it means that I’ve most probably omitted > or > > mistyped some punctuation mark somewhere. However, PHP is unable to tell > me > > where exactly is the error: it tells only the line number, and I have to > > carefully scan the entirely line to find the place. Sometimes, I resort > to > > split the offending line in several ones, so that I could get more > precise > > location info. > > > > So please, let the parser tell me not only the line of the error, but > also > > the column. Then, it doesn’t matter how the offending token is named if > you > > know where it is. > > > > —Claude > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > I have a reputation on this list for being rather conservative about changes. I'm somewhat sympathetic to the symbolic reasons for keeping it around. I don't think such reasons outweigh the benefits though. The only valid solution I would support that didn't rename the token would be if we removed that token from the error messages altogether. I think that would be more likely to cause issues, though, since there could be tests that need SOME sort of token specified. -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV][RFC] Rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
OMG the trolling continues even today with this nonsense. Disappointing. Calling T_PAAMAYIM_NEKUDOTAYIM a non-issue is simply wrong and here's why:: "People don’t ask for the other parse errors even half as often as they as for T_PAAMAYIM_NEKUDOTAYIM They do so because it looks like gibberish to them, so it looks unlikely to be a common thing you can Google, nor it gives something recognizable to start with [sic] Yes, we all acknowledge it’s an easter egg joke that refers to the creators of PHP. But that particular joke has outworn its welcome in the community after repeatedly CAUSING SUPPORT ISSUES." -Stan Vass (emphasis mine) "It's a minor change and an annoyance to a lot of people. Yes, by not changing this you’re annoying thousands of people." -Alexander Schrijver "It’s the same argument everyone else is giving, and really it all comes down to this.: Nostalgia is valued over clarity and consistency. Do you guys REALLY want to claim that?" -Chad Minick "...yes, it is broken, people have to Google or ask around for a very unclear error message when for the most part errors are (and should be) self explanatory ...Two things are broken: Either the token is named badly, or the token names shouldn’t show up in error messages at all and be replaced with something a bit more friendly. ...What is so hard to believe when people see UNEXPECTED T_DOUBLE_COLON on LINE 23 they are gonna look for a double colon on line 23?" -Chad Minick Once again I plead for logic and sanity. At least have the courage to put it to a vote. On Wed, Jun 10, 2020, 12:28 PM Claude Pache wrote: > Hi, > > I appreciate the effort to reduce frustration in PHP coding. > > However, T_PAAMAYIM_NEKUDOTAYIM is a non-issue: you learn it once and > you’re done for the rest of your life. > > May I suggest an improvement that would be much more useful than renaming > tokens? > > One parsing error that I still find dreadful after more than 10 years of > PHP coding, is: unexpected T_CONSTANT_ENCAPSED_STRING. Although > T_CONSTANT_ENCAPSED_STRING is like Hebrew for me, I’ve learned with time > that when I get such an error, it means that I’ve most probably omitted or > mistyped some punctuation mark somewhere. However, PHP is unable to tell me > where exactly is the error: it tells only the line number, and I have to > carefully scan the entirely line to find the place. Sometimes, I resort to > split the offending line in several ones, so that I could get more precise > location info. > > So please, let the parser tell me not only the line of the error, but also > the column. Then, it doesn’t matter how the offending token is named if you > know where it is. > > —Claude > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
[PHP-DEV] 8.0 release dates
TL;DR - Good news everyone! You have an extra week before feature freeze, and GA is coming earlier than expected! As alpha1 approaches, I was reviewing the scheduled release dates for 8.0 and noticed that we were offset from the active branch releases by 1 week. In the interest of keeping releases aligned, and in consultation with my co-release manager Gabriel as well as other RMs, I've decided to postpone alpha1 by a week, meaning that alpha2 will coincide with the release of 7.4.8 and 7.3.20. We'll also be removing RC6 (we have a LOT of pre-releases after all) such that 8.0.0 GA will align with the release of 7.4.13 and 7.3.25. The upshot, as stated in the TL;DR above is that folks trying to get last-minute features into the language/runtime have an extra week before feature freeze (previously Jul 28th, now Aug 4th), and users should expect 8.0.0-final a week earlier (previously Dec 3rd, now Nov 26th). Obviously, this schedule is still subject to change if we find problems during the pre-release which warrant additional time. You may find the revised schedule at https://wiki.php.net/todo/php80 -Sara Golemon
Re: [PHP-DEV][RFC] Rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
Hi, I appreciate the effort to reduce frustration in PHP coding. However, T_PAAMAYIM_NEKUDOTAYIM is a non-issue: you learn it once and you’re done for the rest of your life. May I suggest an improvement that would be much more useful than renaming tokens? One parsing error that I still find dreadful after more than 10 years of PHP coding, is: unexpected T_CONSTANT_ENCAPSED_STRING. Although T_CONSTANT_ENCAPSED_STRING is like Hebrew for me, I’ve learned with time that when I get such an error, it means that I’ve most probably omitted or mistyped some punctuation mark somewhere. However, PHP is unable to tell me where exactly is the error: it tells only the line number, and I have to carefully scan the entirely line to find the place. Sometimes, I resort to split the offending line in several ones, so that I could get more precise location info. So please, let the parser tell me not only the line of the error, but also the column. Then, it doesn’t matter how the offending token is named if you know where it is. —Claude -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV][RFC] Rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
(Trying again without a plussed address, which is too much hassle for the ML. Sorry for dups.) Honestly, I'd rather PHP didn't barf raw lex tokens to the end user for its output. But until then, renaming it seems wise. Didn't someone come out and claim that the current token is misspelled Hebrew anyway? --c -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV][RFC] Rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
Encountering T_PAAMAYIM_NEKUDOTAYIM is a right of passage in the PHP world. I had to deal with it, so should everyone else. :-P While it'll be bittersweet to see it go, I definitely think this would be a wise update. On Wed, Jun 10, 2020 at 12:58 PM Ryan Jentzsch wrote: > With over 25+ years of software development experience it was In 2016 I was > introduced to the world of PHP development. > One day I came across the most unusual of error messages > "T_PAAMAYIM_NEKUDOTAYIM" What the hell is this?!? > That I needed to waste my time to Google this is simply insane. At the time > I thought to myself that PHP deserved some of the hate. Then I came across > this gem: https://phil.tech/2013/t-paamayim-nekudotayim-v-sanity/ > Please for the sake of logic and sanity replace this nonsense with > T_DOUBLE_COLON > > On Wed, Jun 10, 2020, 9:14 AM G. P. B. wrote: > > > Greetings PHP internals, > > > > Kalle Sommer Nielsen and myself are proposing to rename the > > T_PAAMAYIM_NEKUDOTAYIM > > token into the already existing T_DOUBLE_COLON alias, > > T_PAAMAYIM_NEKUDOTAYIM would then become an alias to T_DOUBLE_COLON. > > > > The RFC is located here: > > https://wiki.php.net/rfc/rename-double-colon-token > > > > Although this token is a nod to the valuable contributions made by the > > Isrealie community we believe this token is rather confusing for > newcomers. > > Moreso, as PHP is for many people their first programming language, > > they may not have some of the habits like googling errors when > > they are stuck, which leads to a frustrating experience. > > > > As we believe PHP still has many years of existence we think it is time > > to rename this token. > > > > This is backwards compatible with PHP 7 and 5. > > This RFC does not lay out a plan for deprecating T_PAAMAYIM_NEKUDOTAYIM > > and leaves this as a future scope. > > > > As the matter on hand is a relatively straight forward yes/no vote we > > expect > > it to be held after the minimum 2 week discussion period. > > > > Best regards > > > > George Peter Banyard > > > -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV][RFC] Rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
With over 25+ years of software development experience it was In 2016 I was introduced to the world of PHP development. One day I came across the most unusual of error messages "T_PAAMAYIM_NEKUDOTAYIM" What the hell is this?!? That I needed to waste my time to Google this is simply insane. At the time I thought to myself that PHP deserved some of the hate. Then I came across this gem: https://phil.tech/2013/t-paamayim-nekudotayim-v-sanity/ Please for the sake of logic and sanity replace this nonsense with T_DOUBLE_COLON On Wed, Jun 10, 2020, 9:14 AM G. P. B. wrote: > Greetings PHP internals, > > Kalle Sommer Nielsen and myself are proposing to rename the > T_PAAMAYIM_NEKUDOTAYIM > token into the already existing T_DOUBLE_COLON alias, > T_PAAMAYIM_NEKUDOTAYIM would then become an alias to T_DOUBLE_COLON. > > The RFC is located here: > https://wiki.php.net/rfc/rename-double-colon-token > > Although this token is a nod to the valuable contributions made by the > Isrealie community we believe this token is rather confusing for newcomers. > Moreso, as PHP is for many people their first programming language, > they may not have some of the habits like googling errors when > they are stuck, which leads to a frustrating experience. > > As we believe PHP still has many years of existence we think it is time > to rename this token. > > This is backwards compatible with PHP 7 and 5. > This RFC does not lay out a plan for deprecating T_PAAMAYIM_NEKUDOTAYIM > and leaves this as a future scope. > > As the matter on hand is a relatively straight forward yes/no vote we > expect > it to be held after the minimum 2 week discussion period. > > Best regards > > George Peter Banyard >
Re: [PHP-DEV] RFC: separate inheritance from subtyping (PHP v8)
On Wed, Jun 10, 2020, at 11:16 AM, Doug Wilbourne wrote:
> I propose the following language additions:
>
>
>
> 1) add three new keywords to the available syntax for class declarations:
> 'inherits' and 'subtypes' and 'patterns'.
>
>
>
> Currently the 'extends' keyword means both inherits and subtypes,
> which leads to unnecessarily restrictive typing problems in order to
> satisfy the Liskov substitution principle. 'Inherits' would mean that
> class A inherits B's properties and methods but is not a subtype of B and
> cannot be substituted for B. And just as A can override/overload B's
> methods, the method signatures would not be subject to the parameter
> widening / return-type restricting principle necessary for substitution.
> Conversely, the 'subtypes' keyword indicates that if A subtypes B then A
> can be substituted anywhere B can be used but 'subtypes' does not imply
> that A inherits any of B's methods and properties - simply that it has
> signatures that conform to the parameter widening and return-type
> restricting principles of substitution. Lastly 'patterns' complements the
> 'implements' keyword. A class 'patterns' an interface if it conforms to
> the declared signature of the interface but it does not imply that the
> concrete class can be substituted for any other object which either
> implements or patterns the interface.
>
>
>
> It should be possible to write 'A inherits, subtypes B' and this should
> have the same effect as 'A extends B'.
>
>
>
> 2) Add two new operators: 'descendentof' and 'subtypeof' that would augment
> 'instanceof'. Semantics parallel the class declaration keywords described
> above.
>
>
>
>
>
> Benefits:
>
>
>
> It would then be possible to write something like the following:
>
>
>
> interface ValidatorInterface
>
> {
>
> public function validate($x) : bool;
>
> public function getErrmsg() : string;
>
> }
>
>
>
> abstract class Validator patterns ValidatorInterface
>
> {
>
> abstract public function validate($x) : bool;
>
>
>
> public function getErrmsg() : string
>
> {
>
> return $this->errmsg;
>
> }
>
> }
>
>
>
> class ValidatorNonNegativeInteger inherits Validator patterns
> ValidatorInterface
>
> {
>
> public function validate(int $x) : bool { return 0 <= $x; }
>
> }
>
>
>
> class ValidatorAlphaText(string $x) inherits Validator patterns
> ValidatorInterface : bool
>
> {
>
> return 1 == preg_match('/^[a-zA-Z]+$/', $x);
>
> }
>
>
>
> ValidatorNonNegativeInteger and ValidatorAlphaText cannot be substituted
> for each other or Validator or ValidatorInterface. Explicitly trying to
> upcast ValidatorNonNegativeInteger should produce a compiler error (e.g.
> (Validator) new ValidatorNonNegativeInteger() is not legal).
>
>
>
> If you adopt the data type 'mixed' and use it as in "public function
> validate(mixed $x)", it makes it even clearer that the syntax permits
> covariant parameters.
>
>
>
> Currently the compiler allows contradictory parameter declaration between
> parent and descendant (using 'extends') but produces a runtime error
> indicating that the child method's parameter must conform to that of the
> parent. Because substitution is not an issue when A inherits B (using
> ‘inherits’ as above, not ‘extends’), a parent declaring "function foo(int
> $bar)" and a descendant declaring "function foo(string $bar)" has no
> theoretical problem as far as I can tell and should not produce an error.
>
>
>
> Along with generics (already being suggested / discussed I think - and
> thank you for unions), this approach should lead to DRYer code and cleaner
> abstractions. In the example above, ValidatorNonNegativeInteger and
> ValidatorAlphaText can leverage common code in the parent class. And it is
> not necessary to write two separate interfaces in order to handle the two
> different data types. Essentially, it creates a bridge between the old
> 'untyped' Zvals and the tightly typed C derivatives.
>
>
>
>
>
> Who Is Going To Write This?
>
>
>
> I am relatively new to the PHP community and have never once glanced at the
> internals of PHP. As much as I would love to do it, my learning curve will
> be quite some time before I would be ready to tackle something like this.
> And I think the time for this idea is now while there is so much momentum
> in the community on type-safety. I am considering getting involved in the
> community per the guidance (test writing, documentation, etc) but have not
> plucked up the courage to make the commitment yet. And my C is super
> rusty. If this falls on deaf ears, I am afraid the idea will never bear
> fruit. If everyone thinks it is a good idea, then I am particularly sorry I
> cannot do it myself since it is wrong to make my problem someone else’s
> problem. I would consider writing something in PHP to implement the idea,
> but cannot really see how it could be accomplished.
>
>
>
> Thank you for your t
[PHP-DEV] RFC: separate inheritance from subtyping (PHP v8)
I propose the following language additions:
1) add three new keywords to the available syntax for class declarations:
'inherits' and 'subtypes' and 'patterns'.
Currently the 'extends' keyword means both inherits and subtypes,
which leads to unnecessarily restrictive typing problems in order to
satisfy the Liskov substitution principle. 'Inherits' would mean that
class A inherits B's properties and methods but is not a subtype of B and
cannot be substituted for B. And just as A can override/overload B's
methods, the method signatures would not be subject to the parameter
widening / return-type restricting principle necessary for substitution.
Conversely, the 'subtypes' keyword indicates that if A subtypes B then A
can be substituted anywhere B can be used but 'subtypes' does not imply
that A inherits any of B's methods and properties - simply that it has
signatures that conform to the parameter widening and return-type
restricting principles of substitution. Lastly 'patterns' complements the
'implements' keyword. A class 'patterns' an interface if it conforms to
the declared signature of the interface but it does not imply that the
concrete class can be substituted for any other object which either
implements or patterns the interface.
It should be possible to write 'A inherits, subtypes B' and this should
have the same effect as 'A extends B'.
2) Add two new operators: 'descendentof' and 'subtypeof' that would augment
'instanceof'. Semantics parallel the class declaration keywords described
above.
Benefits:
It would then be possible to write something like the following:
interface ValidatorInterface
{
public function validate($x) : bool;
public function getErrmsg() : string;
}
abstract class Validator patterns ValidatorInterface
{
abstract public function validate($x) : bool;
public function getErrmsg() : string
{
return $this->errmsg;
}
}
class ValidatorNonNegativeInteger inherits Validator patterns
ValidatorInterface
{
public function validate(int $x) : bool { return 0 <= $x; }
}
class ValidatorAlphaText(string $x) inherits Validator patterns
ValidatorInterface : bool
{
return 1 == preg_match('/^[a-zA-Z]+$/', $x);
}
ValidatorNonNegativeInteger and ValidatorAlphaText cannot be substituted
for each other or Validator or ValidatorInterface. Explicitly trying to
upcast ValidatorNonNegativeInteger should produce a compiler error (e.g.
(Validator) new ValidatorNonNegativeInteger() is not legal).
If you adopt the data type 'mixed' and use it as in "public function
validate(mixed $x)", it makes it even clearer that the syntax permits
covariant parameters.
Currently the compiler allows contradictory parameter declaration between
parent and descendant (using 'extends') but produces a runtime error
indicating that the child method's parameter must conform to that of the
parent. Because substitution is not an issue when A inherits B (using
‘inherits’ as above, not ‘extends’), a parent declaring "function foo(int
$bar)" and a descendant declaring "function foo(string $bar)" has no
theoretical problem as far as I can tell and should not produce an error.
Along with generics (already being suggested / discussed I think - and
thank you for unions), this approach should lead to DRYer code and cleaner
abstractions. In the example above, ValidatorNonNegativeInteger and
ValidatorAlphaText can leverage common code in the parent class. And it is
not necessary to write two separate interfaces in order to handle the two
different data types. Essentially, it creates a bridge between the old
'untyped' Zvals and the tightly typed C derivatives.
Who Is Going To Write This?
I am relatively new to the PHP community and have never once glanced at the
internals of PHP. As much as I would love to do it, my learning curve will
be quite some time before I would be ready to tackle something like this.
And I think the time for this idea is now while there is so much momentum
in the community on type-safety. I am considering getting involved in the
community per the guidance (test writing, documentation, etc) but have not
plucked up the courage to make the commitment yet. And my C is super
rusty. If this falls on deaf ears, I am afraid the idea will never bear
fruit. If everyone thinks it is a good idea, then I am particularly sorry I
cannot do it myself since it is wrong to make my problem someone else’s
problem. I would consider writing something in PHP to implement the idea,
but cannot really see how it could be accomplished.
Thank you for your time and consideration. And thank you so much for all
the work you do to make PHP the product that it is.
Kind regards,
Doug Wilbourne
Re: [PHP-DEV] [RFC] Shorter attribute syntax
On Wed, June 10, 2020 at 3:11 AM Michał Brzuchalski
wrote:
> I just noticed a power of Rusts outer attributes which this syntax
> count follow in a future. Following outer attributes in Rust's we
> could introduce in a future syntax like
>
> #![StrictTypes,Module("my_module"),Opcache(save_comments: true)]
>
> The last one used with recently proposed named arguments which could
> open a wide range of possibilities IMO. In Rust adding exclamation
> mark after hash `#!` imposes to take effect on the outer scope which
> inside a file would be the whole file.
>
> Going that path solution like that could possibly supersede
> `declare` statement in a future and allow to add compile-time
> attributes without breaking the language. I believe this is very
> important because any attribute which is not declared as a core and
> built-in is not taking an effect. This way it'd be possible to add
> new ones in future PHP versions. Even more with `zend_ast_process`
> it'd be possible to implement core attributes which take effect on
> whole file in extension.
>
> I can imagine this can possibly be discussed to allow attributes for
> eg. from ctor to take effect on class but am not 100% sure of it is
> useful.
Hi Michał,
I'm really not certain it's a good thing to have another way of adding
declares which would be ignored in older PHP versions. For instance,
in your example if the code is designed to work with stricter types,
what happens if it's unexpectedly run on an older version of PHP?
Instead of erroring as it should, the code might keep running but
produce unexpected results for certain inputs.
> Going further with my imagination if we go that path with `#[Attribute]`
> we may think of adding error suppression.
> I know many don't like error-suppression but sometimes it's helpfull.
>
> In case of core attributes I can imagine a const value can be added
> renamed or removed, but the attribute remains the same then adding
> error suppression in a future allows to avoid crashing like for eg.
>
> #@[Jit(Jit::OPTIMISE_SOMETHING)] // where the const may exists or not,
> but the Jit attribute does
> function foo () {}
>
> In those cases we don't wanna crash the program, we may want it to
> continue rather without proper optimisation then not at all.
>
> I just see another use of current error-suppression operator @ to
> play nice with attributes.
Please, let's not add a new place where error suppression can be used.
Yes, it's necessary when wrapping some old APIs that otherwise output
warnings, but for new APIs I really don't think this is a good idea.
Best regards,
Theodore
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV][RFC] Rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
Greetings PHP internals, Kalle Sommer Nielsen and myself are proposing to rename the T_PAAMAYIM_NEKUDOTAYIM token into the already existing T_DOUBLE_COLON alias, T_PAAMAYIM_NEKUDOTAYIM would then become an alias to T_DOUBLE_COLON. The RFC is located here: https://wiki.php.net/rfc/rename-double-colon-token Although this token is a nod to the valuable contributions made by the Isrealie community we believe this token is rather confusing for newcomers. Moreso, as PHP is for many people their first programming language, they may not have some of the habits like googling errors when they are stuck, which leads to a frustrating experience. As we believe PHP still has many years of existence we think it is time to rename this token. This is backwards compatible with PHP 7 and 5. This RFC does not lay out a plan for deprecating T_PAAMAYIM_NEKUDOTAYIM and leaves this as a future scope. As the matter on hand is a relatively straight forward yes/no vote we expect it to be held after the minimum 2 week discussion period. Best regards George Peter Banyard
Re: [PHP-DEV] [RFC] Shorter attribute syntax
Hi Sebastian,
On Wed, June 10, 2020 at 12:37 AM Sebastian Bergmann wrote:
> Am 09.06.2020 um 17:57 schrieb Theodore Brown:
> > That's an interesting argument. After thinking about it more, though,
> > I'm not sure I understand what the benefit would be. The docblock
> > annotation needed for PHP 7 is *already* forward compatible with PHP 8.
> > So wouldn't this just be duplicating the attribute and opening the
> > possibility for them to be out of sync for no benefit?
>
> This would allow the introduction of classes into PHPUnit such as
>
> namespace PHPUnit\Attribute;
>
> #[Attribute]
> final class Covers
> {
> private string $coverageTarget;
>
> public function __construct(string $coverageTarget)
> {
> $this->coverageTarget = $coverageTarget;
> }
>
> // ...
> }
>
> that can be used to encapsulate information that may come from a ...
>
> /**
> * @covers \Foo\Bar\Baz
> */
>
> ... DocBlock-style annotation in PHP 7 but may also come from an ...
>
> #[Covers(Baz::class)]
>
> ... attribute when PHP 8 is used.
>
> This would make forward compatibility possible in code such as PHPUnit's
> that currently supports DocBlock-style annotations but wants to support
> PHP 8 attributes and to deprecate (and later remove) support for
> DocBlock-style annotations.
So is the idea that PHPUnit 10 would still run on PHP 7.x, but would
also support native attributes for people running PHP 8? Maybe I'm
missing something, but wouldn't this be possible with the `@@` syntax
as well? The new `Covers` class would only be loaded if someone is
using attributes on PHP 8, so it's fine if it uses new PHP 8 syntax.
A parent class could be used to encapsulate coverage info for PHP 7.x.
To me it seems like the benefit of having (single-line-only) PHP 8
attributes treated as comments in PHP 7.x is being overblown. There
is already an upgrade path for docblock annotations to attributes.
Docblocks will continue working perfectly fine in PHP 8, so projects
and libraries can wait as long as needed before migrating to the
native attribute syntax.
Using `#[]` as the attribute syntax actually runs the risk of making
it *harder* for users to upgrade to PHP 8, since existing code that
uses hash comments starting with a left bracket would break.
Anyway, our plan is to hold a ranked-choice vote in the RFC between
`@@`, `#[]`, and `<<>>` syntax options, so if people prefer the
tradeoffs of borrowing Rust's syntax they can vote for it.
Best regards,
Theodore
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Shorter attribute syntax
wt., 9 cze 2020 o 13:56 Benjamin Eberlei napisał(a):
> On Thu, Jun 4, 2020 at 1:55 AM Theodore Brown
> wrote:
>
> > Hi internals,
> >
> > I discussed the syntax for attributes further with Benjamin, Martin,
> > and several other internals developers off-list, and with their
> > feedback completed an RFC proposing to use the shorter `@@` syntax
> > instead of `<<>>` for attributes in PHP 8.
> >
> > https://wiki.php.net/rfc/shorter_attribute_syntax
> >
> > The goal is not to bikeshed over subjective syntax preferences,
> > but to address several concrete shortcomings related to verbosity,
> > nested attributes, confusion with generics and other tokens, and
> > dissimilarity to other common languages.
> >
>
> Larry's suggestion about #[Attr] makes an important argument about allowing
> to declare attributes in code in PHP 7 in a forward compatible way that has
> not been brought up before.
>
> /** @ORM\Entity */
> #[ORM\Entity]
> class User {}
>
> This code would work on PHP 7 and 8.
>
> The #[] syntax would have about equally low breaking potential as @@. It
> would be the same syntax as Rusts, and close to C++/C# syntax.
>
I just noticed a power of Rusts outer attributes which this syntax count
follow in a future.
Following outer attributes in Rust's we could introduce in a future syntax
like
