On Wed, Jul 10, 2024 at 3:29 PM Rowan Tommins [IMSoP] <imsop....@rwec.co.uk>
wrote:
>
>
> On 10 July 2024 19:08:39 BST, Michael Morris <tendo...@gmail.com> wrote:
>
> Just to repeat a point that's been raised a few times: this is not a great
> time of year for this kind of discussion. If you come back after 8.4 is
> baked, you may get more enthusiasm. That will also give you time to make
> some more detailed analysis, so we don't have to argue about hypothetical
> difficulties.
>
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.
>
> >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.
>
> >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.
>
>
> > 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.
