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.
>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.
>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.)
> 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.
Regards,
Rowan Tommins
[IMSoP]
