On 10 July 2024 19:08:39 BST, Michael Morris <[email protected]> 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]