> On Jul 3, 2024, at 6:16 PM, Michael Morris <tendo...@gmail.com> wrote:
>
> Hello all. Hitting reset again as the primary problem at hand has become
> clear. Let's recap it.
>
> Autoloading is great for loading packages, but it can't load different
> versions of the same package at the same time. Why would you want to do that?
>
> When you don't have full control of the code.
>
> For example, consider Drupal. It is running Twig at some version of 3 at the
> moment. Suppose Twig 4 is introduced with significant backward compatibility
> breaks (Not saying the authors would do such a thing) but also wonderful
> features.
> …[snip]...
> This is why I advocate a new keyword for this - import. Import’s behavior is
> most similar to require_once, but it doesn't have to be the same. Since it
> is a new entrypoint into the engine the way the engine considers the code can
> be different - whether slightly different or radically different is a debate
> for another time. I'm going to stick with only those changes that make sense
> in the context of package links.
I’m seeing a lot of conflation of ‘module’ and ‘package’ in these discussions,
and to me they mean different things:
* A module is a sort of “first class namespace” that can export symbols and
import others. Think ES5 or python modules. If you don’t want it 1-1 with
files, think Perl modules.
* A package is an “installable” unit that provides modules, among other things.
Packages have metadata, the most important piece of which is a
machine-readable version.
Certainly there’s overlap between the two, but the first is a more low-level
thing that doesn’t need worry itself about versioning let alone multiple
simultaneous versions. I just don’t want to see the possibility of having
basic “import” and “export” functionality crushed under the bikeshed while all
the fine semantics of versioning are worked out.
—c
