On Tue, May 21, 2024, 13:18 Koichi Murase <myoga.mur...@gmail.com> wrote:
> 2024年5月21日(火) 14:56 Phi Debian <phi.deb...@gmail.com>: > > Apparently konsolebox wrote a package manager, and survived the source > 'as > > is', yet he still advocate for 'enhancement'. I do have a package manager > > too, and survived source 'as is' and don't require any enhancement. > > I'm not sure if it is the case for konsolebox, but I think it is valid > to suggest including the features that turned out to be useful in > maintaining a package manager as built-in ones. Those suggested > features are meant to replicate the useful part of the features of the > package manager, so it is not surprising that the suggested features > are not needed for the package manager itself. > > That said, I think it would be difficult to reach an agreement on the > detailed behavior of the suggested features to make them consistent > with many existing package managers. > > > 'May be' bash could investigate the ksh93/zsh $FPATH autoload, but don't > > know if that would be good enough for the initial purpose. > > There are already shell-function implementations at > /examples/functions/autoload* in the Bash source. They reference FPATH > to load functions, though one needs to call `autoload' for each > function in advance (by e.g. `autoload "$fpath_element"/*' ). > > However, I personally do not think the FPATH mechanism is useful > because a file can only contain one function per file. Significantly > non-trivial functions are usually implemented by a set of helper > functions or sub-functions. Also, in libraries, we usually have a set > of functions that are closely related to one another and share the > implementations. I don't think it is practical to split those > functions into dozens or hundreds of files. It would also be slow to > read many different files, which requires access to random positions > on the disk. > for the overall thread : sorry , i cant read that much text of ya' all but i have a question and related information to share question : is this one-thing-per-file sourcing ? i made long ago a project that has different dirs , contain different type of files ( function , alias , .. ) each one per file , and the name of the file , in the dir , is then its identifier in the code say proj/func/bla will result in bla() with the files comtent .. is it such u discuss here .. if so .. i have big experience and wanna talk more about such just .. .. greets .. -- > Koichi > >
