> I think every single use of the term "library" in this whole endeavor
> is misleading and misguided.
I don't think so. A library is just a logical collection of code and data
that you can use to implement software. This is a mechanism meant
to load those libraries separately from executables.
The same reasons which justify having separate /usr/{bin,lib}
also justify this feature. The library directories are not placed
in the PATH even though shared objects might be executable.
The binary directories on the other hand are placed in the PATH
even though executables might also be libraries at the same time.
It's all about how the developer intends the software to be used.
This loading mechanism makes it easy to use in the intended way.
That's all.
> It implies something unique about the files being sourced
I don't think it necessarily implies anything about the scripts
other than the purpose for which they were written.
Usually, executables perform concrete tasks
while libraries merely provide the building blocks
necessary for accomplishing said tasks.
That's the only general implication that may be drawn.
It does not necessarily need to be that way but it usually is.
> when in fact there is nothing special about them at all
> they can still run arbitrary code, modify the global namespace,
> etc. etc. etc. etc.
This is also true in essentially every other programming language.
There is nothing special about libraries, it's just code and data.
They usually provide the building blocks for building an executable
but that's not actually mandated.
Dynamic languages have libraries which are literally just scripts
that are evaluated when imported. Essentially the same thing
that's being proposed here. Their library systems consist of an
in-language loading mechanism, which this patch implements,
and also usually an external package manager and repository
which is out of scope here and not actually necessary.
Even static compiled shared objects are not actually static
collections of functions and variables, they can and do have
things such as init/fini sections which run arbitrary code
implicitly when they are loaded and unloaded. They had to
implement topological sorting in the dynamic linker for this.
The dynamic linker actually does dependency resolution.
I think that's actually kind of insane but somebody needed it
and they made it happen.
Some languages have isolated modules, others don't.
Some natively support namespacing, others don't.
The most common complication among them is
the load-once mechanism: usually only a single copy
of a library is ever loaded by the interpreter, no matter
how many times it's referenced.
I am of course open to discussing and implementing all of
these additional semantics. In the previous email thread,
I said I was even hoping to have this discussion.
However, the lack of these semantics does not preclude
bash from having a library system. It's already functional.
I think load-once is important and should be implemented
but opinions appeared to diverge in the comments to my first
patch set so I would rather wait for consensus before doing it.
-- Matheus
