« first day (5021 days earlier)   

2:45 PM
@QuolonelQuestions The “How To” page should probably be rewritten to match the current reality better. I guess that most of the active RFC writers don't really look at that page any more and just work based on their experience and the RFC template that is automatically loaded.
Voting on the implementation is not really a thing, as Ilija already said.
@QuolonelQuestions Sorry, was off my computer on the weekend, but the answer would've been "didn't read the RFC yet" either way.
 
1 hour later…
3:59 PM
The template for a new RFC is also pretty solidly wrong, too. It still claims PHP is an untyped language. :-)
you can fix the template... it's a wiki, not? :-)
I don't know where the template even is.
And don't want to get yelled at. :-)
4:29 PM
wiki.php.net/rfc/template — it says so right at wiki.php.net/rfc ;-)
So how many people will I piss off if I start editing that? :-P
you can always put up an RFC about it :-D
It's a quote though, so not something you can just change.
I figured I'd just remove the quotes from people who haven't been involved in the project for years...
4:50 PM
Crell inviting the wrath from high upon the thing
 
2 hours later…
6:22 PM
@TimWolla It's not likely to matter. Approval is already below 50%
Even though people have been trying to introduce it for 16 years
6:47 PM
I don't want static classes because I think people need to get over functo-phobia, but I don't see any reason to forbid this.
Partially because namespace-private functions aren't a thing. Wish we had a better module system, but I don't even want to look inside that discussion thread >.<
7:44 PM
lol thanks for your vote :)
8:14 PM
>I think people need to get over functo-phobia
Is your meaning that you're also from the namespaced functions camp primarily?
9:12 PM
@QuolonelQuestions Yes. Functions are fine. People are obsessed with autoloading and such. Preload the functions, it's not going to be a problem at all...
I think there's also something to be said for prefixing the call with a meaningful grouping identifier (the class name) which can be applicable in some situations
And something to be said for adding one import for a collection of functions you're likely to use together instead of one per function
But I didn't make any arguments for any of that in the RFC because it was never the point to push for a particular pattern over another
It's the sort of feature you can just ignore if it's of no value to you
@QuolonelQuestions You know... like putting them in the same file...
The file itself does not form part of the call in the code
9:52 PM
use My\Functional\Library as functional;

functional\some_func();
That works.
Yet almost no-one will use it because it has to be done manually in most cases.
Good thing I didn't make that argument then :^)
 
1 hour later…
11:10 PM
@QuolonelQuestions "In particular, classes with a private constructor can still be instantiated via reflection and faux-deserialization hacks." Just use an enum with no cases. :D
FWIW, I think you did a good job with both writing and implementation. You mostly just picked a somewhat controversial first RFC. ^^
@IluTov, not sure yet what commit it is running on, but seems like PHP_CS_FIXER is hitting some new parser issues github.com/PHP-CS-Fixer/PHP-CS-Fixer/actions/runs/9946462553/…
I don't know if it's related to the from /* comment */ yield or maybe the merging of property hooks?
@Girgias The yield thing is present since 8.3, so probably not that.
It uses commit 85b7181d7dd6e155a74d0392e1fd20e41b9768a1 so probably property hooks then
@IluTov Thanks man, that means a lot :^)
Kinda crazy it's still considered controversial after 16 years of people trying to add the same feature
I am not sure why time would make an idea less controversial?
11:16 PM
@Girgias I think it comes from: <?php foo($bar{"mode"} & $baz);, which was removed fully in this RFC.
@Girgias Apparently it made it MORE controversial
@IluTov Passed the info onwards
@Girgias Thanks
[9 years ago](https://externals.io/message/79211#79212) Marco said:
>I can really see a lot of cases where I needed this: badly.

Today he votes against it
@QuolonelQuestions I will be honest, I didn't really follow the discussion on the ML as sooooo much traffic, but this just makes me go and try and wrap up the function autoloading RFC
@QuolonelQuestions People can change their mind, and realize that maybe something is not that good an idea after having dealt with it
11:18 PM
@Girgias Every time someone brings this up I see it as a false equivalence
I would still propose this, exactly as it is now, if function autoloading was a thing
Static classes are a poor man's "module"
Because OOP is, well a design choice that I think most people are realising ain't ideal
Well, correction, to me they feel like a poor man's "module"
If we had modules that would be great. And static classes would not stand in the way of introducing modules
The point is that, IMHO, the "solution" is modules, not static classes
It's not because we can have both that we should
We have static classes whether you like it or not. Just implicitly rather than explicitly, and that's not a far reach
I can't think of anything I thought 9 years ago that I still think today, except for like basic things like "murder is bad"
11:29 PM
@QuolonelQuestions I think static classes are not a good idea, thus I don't think the language should encourage it.
It's not encouraging. It's just reflecting reality
Okay, you are missing the point, I will stop arguing
No, I hear you. Modules are the way
But I disagree that they must be mutually exclusive. How long are we supposed to wait for this modules vaporware?
The discussion about any idea of modules just occurred, checks notes, this past month
And I'm not sure how fruitful that conversation was, as it sprawled into so many threads with so many messages, but I know some people have been collating ideas
It's not because something is technically feasible really easily that it should be done. 3/4 of SPL is that and it is a horrible thing

« first day (5021 days earlier)