Re: [PHP-DEV] Reflection*::hasAttribute()
> I think that would require an RFC. Alright, thanks. > To clarify, you're proposing to replace this: >count((new ReflectionClass(Beep::class))->getAttributes(Ignore::class)) == true >with >(new ReflectionClass(Beep::class))->hasAttribute(Ignore::class) > Right? Correct. > That doesn't seem like a huge improvement. Probably not a huge one indeed, yet it makes the intent more clear for the use case at hand. Given such attributes are getting more and more common in userland, not only in frameworks, I tend to think it's worth considering. >Actually, > >if ((new ReflectionClass(Beep::class))->getAttributes(Ignore::class)) > >would work as well, so basically: > >$rc->hasAttribute(Ignore::class) === (bool) >$rc->getAttributes(Ignore::class); Yes, (ab)using `getAttributes()` for that purpose is certainly not a big deal, just like using `strpos()` for word detection was not. But `str_contains()` came up as it’s semantically better. Probably worth adding that such method looks consistent with other parts of the Reflection API like `hasProperty()`, `hasMethod()`, `hasConstant` or `implementsInterface()`. About other languages, Java has `isAnnotationPresent()` and C# has `Attribute.IsDefined()` - both serving the exact same purpose. -- Robin Chalas
Re: [PHP-DEV] Reflection*::hasAttribute()
> > I think that would require an RFC. > > To clarify, you're proposing to replace this: > > count((new ReflectionClass(Beep::class))->getAttributes(Ignore::class)) == > true > > with > > (new ReflectionClass(Beep::class))->hasAttribute(Ignore::class) > > Right? That doesn't seem like a huge improvement. > > --Larry Garfield Actually, if ((new ReflectionClass(Beep::class))->getAttributes(Ignore::class)) would work as well, so basically: $rc->hasAttribute(Ignore::class) === (bool) $rc->getAttributes(Ignore::class); - Benjamin >
Re: [PHP-DEV] [VOTE] Interface Default Methods
On Wed, Jul 12, 2023, at 4:00 AM, G. P. B. wrote: > On Mon, 3 Jul 2023 at 01:11, Levi Morrison wrote: > >> Chatter on the [Interface Default Methods RFC][1] has been quiet for >> the past 6 days, and the feature freeze deadline is fast approaching >> for PHP 8.3, so I'm moving this to vote. It'll be open for two weeks >> as usual. >> >> Thanks to everyone who discussed weaknesses in the RFC during the >> discussion phase. >> >> [1]: https://wiki.php.net/rfc/interface-default-methods >> > > Although I like the idea, I think the main reason for the pushback is how > close this is being voted on before feature freeze when the RFC + > implementation was updated very recently before. > And personally I think, considering this, I would also delay implementing > this. > We have at least 2 other major RFCs that are being pushed back (Property > Hooks and Function autoloading) due to time constraints. > > Maybe it's time for a more meta discussion about the absurdly long release > process PHP has of releasing many intermediate versions that seem to get no > testing from userland. > > For everyone against this feature, I would urge you to understand the > distinction between "type classes" and Java-like "interfaces" (which is > effectively what PHP interfaces are). > A good article is the following one: > https://diogocastro.com/blog/2018/06/17/typeclasses-in-perspective/ > > I also find it baffling the lack of understanding around this feature. > Generic programming exists, and it operates on a level where a method can > have a "concrete" default representation and still represent the genericity > to its fullest. > Examples have already been given, such as the Comparable, Equatable, or > Iterator type classes. > Considering, Haskell, Rust, Scala, and modern PL theory sees no issue with > that, I struggle to understand the resistance here. If I could play armchair shrink for a moment, I suspect a lot of people come from a background where "interface is just the behavior definition, not implementation" was drilled into them. Which... is the case in older Java when most of us went through school using older Java. So it's natural to think that is just a rule of how languages work, and so default methods in interfaces is just some weird nonsense from people who don't understand language theory because you didn't learn it in school. At least, I know that description applies to me, so I'm assuming it applies to at least some other folks around here. :-) Realizing "oh, wait, I was wrong about the theory of how things work" is uncomfortable, and hard for a lot of people. I was initially luke-warm on it for that reason. But seeing how many languages have adopted some form of default methods and lived to tell the tale is convincing for me that it actually is a viable "build up a class from separate pieces without having to manually write 50 proxy methods" solution. There may be smaller issues with it that need to be ironed out (enforcing methods being defined, it working better with interface properties, etc.), but the core idea seems to be sound. It's taken me a while to get used to going through that "oh wait, I was wrong" process, so at this point it's not an ego-hit. But that's not a process everyone has gone through. In short, I suspect at least much of the pushback is "that is weird and not normal, according to the normal I first learned, so it must be a bad idea," and people just stop there. (If you voted no and the above description doesn't apply to you, please do explain what your alternate reasoning is, because RFC authors desperately need more feedback than we get right now.) --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Reflection*::hasAttribute()
On Wed, Jul 12, 2023, at 3:25 AM, Robin Chalas wrote: > Hi internals, > > It is common attributes to be used as markers. Just like a marker > interface with no methods, such attributes don’t have any parameter. > > Examples from Symfony: > - #[Ignore] indicating that a property should be skipped in a > serialization contextl > - #[Exclude] telling the dependency injection container that a given > class should be skipped from automatic service registration > > > From Doctrine ORM: > - #[Id] to tell which property of en entity class should be mapped as > primary key > > Those are meant to opt in/out some behavior through detection only. But > with the current API, such code needs to call `getAttributes()` while > it doesn't care about the returned ReflectionAttribute instances. > Hence I’m wondering if we could add a `hasAttribute()` method to the > reflectors that are targetable by attributes. > > Does that make sense? > If it does, do I need to open an RFC for that feature or is a pull > request be enough? > > Anyway, I’d be happy to work on the implementation as a first > contribution to PHP. > Looking forward to your feedback. > > Thanks. > Robin I think that would require an RFC. To clarify, you're proposing to replace this: count((new ReflectionClass(Beep::class))->getAttributes(Ignore::class)) == true with (new ReflectionClass(Beep::class))->hasAttribute(Ignore::class) Right? That doesn't seem like a huge improvement. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Interface Default Methods
On Wed, Jul 12, 2023 at 5:01 AM G. P. B. wrote: > > Maybe the resistance to the proposal would be far less if the RFC, and > implementation, would check at compile time that the default > implementations only rely on known existing functions available to the > interface. > I asked in the discussion if this was a possibility, and it's the biggest concern I had about the feature as proposed. Rowan answered "As the RFC says, it introduces a form of multiple inheritance, and inheritance in PHP doesn't make any such guarantee" and Levi added "I hope static analysis can fill the gap here, but don't think these checks are necessary to ship this feature" - and this is fair enough, I think; we kind of do accept the nature of PHP is that there is some anti-intuitive weirdness versus statically compiled languages. I wasn't convinced at first but I've come to be persuaded even if it's not a perfect implementation of default methods as I would have wanted them, it's still a significant improvement on the trait + interface model we have now. It's ultimately a step in the right direction and I'm disappointed now it looks like it's not going to happen, at least in the next release. Would be good to know from some of the no votes if they'd reconsider for a future version.
Re: [PHP-DEV] Proposal: Binary type for PDO
> On Jul 9, 2023, at 11:29 AM, Dan Ackroyd wrote: > > On Fri, 7 Jul 2023 at 18:39, Calvin Buckley wrote: >> >> I'd like to hear any oversights, and what could be done to take this >> further. > > I think someone needs to write some code and some tests, and see what happens. > > It's possible that PARAM_BINARY could be used across all of the PDO > drivers that PHP ships with, and for each of them the behaviour with > that option is sensible. > > It's also possible that the behaviour of binary parameters is bespoke > to each of the drivers, and that it isn't possible to use PARAM_BINARY > in a DB agnostic way. > > The most realistic way to find out which option is more real, is to > write the code + testswhich would need to be done anyway, even > assuming the best case scenario. I have a WIP PR here: https://github.com/php/php-src/pull/11674 I have not implemented MySQL/Postgres/OCI/Firebird support, but I have tests for ODBC, DBLIB, and SQLite. I think your suspicions about it being bespoke might be correct, although the exercise isn’t for naught. Even if a PARAM_BINARY isn’t realistic to implement, it still identifies and has some fixes for PDO_ODBC and PDO_DBLIB that could be used independently from any PARAM_BINARY support. Further review and me figuring out the other drivers could help here. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Deprecate remains of string evaluated code assertions
On Wed, 28 Jun 2023 at 17:09, G. P. B. wrote: > Hello internals, > > I'm opening the vote for the > Deprecate remains of string evaluated code assertions RFC: > https://wiki.php.net/rfc/assert-string-eval-cleanup > > It will last for two weeks and end on Wednesday the 12th of July > The vote has now ended. The RFC has been unanimously accepted, with 24 votes in favour. Thank you for everyone that has voted. Best regards, George P. Banyard
Re: [PHP-DEV] [RFC] [Vote] Path to Saner Increment/Decrement operators
On Wed, 28 Jun 2023 at 17:07, G. P. B. wrote: > Hello internals, > > I'm opening the vote for the Path to Saner Increment/Decrement operators > RFC: > https://wiki.php.net/rfc/saner-inc-dec-operators > > It will last for two weeks and end on Wednesday the 12th of July > The vote has now ended. The RFC was accepted unanimously, with 25 votes in favour. Thank you to everyone who has voted. Best regards, George P. Banyard
