On Wed, Jul 10, 2024 at 1:08 PM Michael Morris <tendo...@gmail.com> wrote:
> > > I'm in no rush - though it might not seem that way. I don't see this being > able to land before PHP 10. I'm pessimistic about the scope of these > changes. It can be done - and pieces have often been discussed before, but > they peter out. If they are to be solved some amount of stupid bulldog > tenacity will be needed. I think I'm stupid enough to provide that, but I > need to do it without being annoying. > > In any event these threads have already shown me a great deal of what I > need to learn in order to get to an effective final form, whatever that is. > The point of people asking multiple times to wait until any other time of year is not because anyone is worried you are trying to get it in right away, it's because doing this kind of freeform "I don't know what I don't know" discussion is unkind to all of the experts on the list who CAN tell you "well, what you don't know is X". Most of them probably won't even respond at this time of year, even if they did read, which they probably didn't. > > >> >> >1. Import Maps - These would be prepared by hand or by a package manager >> >like composer. >> >> As Larry mentioned, there was a proposal for this a while ago, but not >> much enthusiasm, since it's so easy to implement in userland, and doing so >> means we don't have to include all the possible options someone might want. >> >> >> > it will be able to detect symbols the autoload >> >system cannot: functions and constants. >> >> Autoloading functions and constants isn't blocked by autoloaders being >> procedural, it's blocked by the unfortunate decision made many years ago >> that a function call like "strlen" dynamically falls back to meaning >> "\strlen", rather than being resolved once at compile-time like class >> names. > > >> So far, nobody's quite cracked how that should interact with autoloading. >> Don't expect this to be easy. >> > > At worst this is the sort of "unfortunate decision" that can be eschewed > in the PHP module files to make them easier to work with. But I really do > need a list of these things we'd love to do but can't because of reasons. > > That's your job as the proposer. :) > >> >2. Packages - Packages load differently and can effectively monkey-type >> the >> >code of an existing package on the fly in much the same way that >> namespaces >> >themselves work with symbol names as a flat string replace. >> >> This is an interesting - but extremely complex - problem, and the one >> I've been urging you to focus on if you're really up for the challenge. It >> probably needs quite a deep dive into how the language works to find out >> what assumptions it's going to break. (If you're just going to talk about >> configuration, and not the actual implementation, don't expect much >> enthusiasm.) >> > > I need to know where to start, beyond cloning the PHP source code repo - > which I have. Any advice on where to look would be appreciated. > Try to change something, compile, then debug a test file with it. That's how I went from "has only done basic C" to "wrote almost all of the implementation of operator overloads" in a few months. Once you start on that, you'll be able to ask more specific questions that are more likely to get a specific and quick response. You'll want to know "when do we use this macro" and so on. You can also reference all the documentation that has been built for people who are getting into learning the PHP source: https://www.phpinternalsbook.com/index.html > >> > Existing code >> >can be loaded into packages, but also an outline for writing packages >> that >> >have privacy modifiers to their members - i.e. protected class SomeClass >> {} >> >> This part seems interesting, as long as it's not tied heavily into other >> changes; existing code using /** @internal */ should ideally need minimal >> changes to make use of it. >> >> >> >> >3. Modules - Files which are code first instead of template first. >> >> If by "template first" you mean "you have to write <?php at the top", I >> repeat my earlier "meh". I'm pretty sure it's also been discussed before, >> and dropped when it met with that general reaction. >> >> The name "modules" implies something more, so maybe I should reserve >> judgement. Having both "packages" and "modules" sounds pretty confusing >> though. >> > > The largest thrust of modules is to step forward with changes that are > desirable but impossible to implement because of BC breaks brought on by > unfortunate design decisions like the one mentioned previously. Likely > these will be visited on a case by case basis. For another is the need of > classes to have the function keyword all over the place. > > It could end up that things like package privacy can only be supported in > the modules. As to the difference, since it meanders all of the place > here's the defs I'm going with - A module is a file. A package is a > collection of files. > So then the purpose of modules, to you, is explicitly to provide features that "can't be done" in PHP? Most of the ones people want are being worked on in some way, even if they "can't be done", so I'm curious what sort of list of features you'll come up with. That feels like it lacks the defining and critical feature of packages and modules in literally every language that has ever had it though: Encapsulation/Restricted Global Scope/Local Symbols If "modules" are not somehow separated in a controllable way, then you aren't building "modules", you're forking PHP. Jordan
