Re: autoload

[Ray Andrews <rayandrews@xxxxxxxxxxx>]

On 09/21/2015 08:19 PM, Bart Schaefer wrote:
> You're not asking for a precompiled function to act like a sourced
> function.  A sourced function, to the extent that means anything at all,
> does nothing but become defined.  But "sourcing" a function (which you
> actually can't do, you can only source a *file*) and "calling" a
> function are two completely distinct things.
I understand, I just chose the wrong word.
>    Rather, you ask for
> compiling a whole file full of defined functions, to behave like
> creating a bunch of undefined ones.
>
> An undefined function (created with "functions -u" aka autoload) does
> both of the source and call operations, but it only knows the one name
> (its own).  So the file (to be sourced) and the function (to be called)
> both have to be identified by that single name.
>
> Could we have created an entire distinct data structure that stores
> both a file name and a function name, and means "oh by the way, when
> you try to run foo, you actually have to go read the file bar" ?
> Yes, we could.  We didn't.  We re-used the existing data structure
> of a function, because one field for the name seemed like enough,
> and the path-search mechanism seemed like a good existing model for
> finding the file.
Ok.  I admit that my notion does presume a table linking functions with 
their
.zwc:

raysfunc    /directory/raysfunc.zwc    line1
somefunc  /directory/all/allfunc.zwc  line40
otherfunc  /directory/all/allfunc.zwc  line200
...

I get a glimpse of how you did what you did within existing structures. 
If I understood
that fully I'd grok the limitations of the system.  I guess it's a bit 
outrageous of me,
but I presumed that in the hash table that links functions to where ever 
they are,
a sort of pointer to a line in a .zwc file would not be a huge problem.
> Further, the point of autoloading was to read into memory exactly
> those functions that are actually used.  If to get foo you have to
> source bar and do everything bar contains, you may end up reading
> (and storing) a hundred functions in order to call one of them.
> Not what we wanted to encourage.  So, one function per file.

That is so insightful, cuz I had exactly the opposite as the supposed 
goal--to
have functions available but not sourced *just in case* you might need them.
I never understood:

    autoload -U colors && colors

... because I'm thinking to myself: 'Why would you 'autoload' something 
that
you are just going to plain vanilla load anyway? Why not just load it 
and be
done with it?' (It doesn't work with compinit.  It seems because 
compinit will
be looking on FPATH for the rest of itself autoloaded, so it's committed to
that method--but you understand my thought.)
> zcompile lets you do two things:  compile a single file to be read by
> source (*) or pack multiple files into an archive to be processed
> by autoload.  But the latter doesn't change the fact that autoload
> needs to match one file (one thing packed in the archive) to one
> function name.

But ... if we have several functions packed in one .zwc it is not 
logically possible
for the name of the file to match the name of more than one of the 
functions which
breaks my head as far as this one-to-one function-file thing.  You tell 
me that
there is this function name - file name requirement but then violate that
commandment by packing in several functions to one .zwc.  I get that if 
a script
is autoloaded it will/must be 'named' after the file it came from. One 
script!
But with functions?  The rule is not followed.

> And the former doesn't magically grant the ability
> to explode the single file into multiple archive entries. (**)
>
> (*) But this is constrained in that both the original file and the
> compiled file have to exist size-by-side, so that source can choose
> the newer of the two.  This constraint isn't strictly necessary.
Well therewego.  Previously you're saying that these .zwc should not be 
in the same
dir, now they should be in the same dir. Nuts, they are created in the 
same dir.  I
tested that by touching the files--as you say, it finds the newest. But 
then you tell
me that best practice is to move the thing :-(  And, speaking of 
philosophy, here
is a case of hand-holding.  The first command found on the path is the 
one used,
and too bad for you if a newer version exists somewhere lower down. It 
doesn't
scan the whole path and load the newest file.  I'm expecting that if I 
autoload
something then it's active and too bad if there's a newer file:

    $ autoload my_function
    $ source /functions/myfunction

... I get the sourced version.

    $ source /functions/myfunction
    $ autoload my_function

... I get the version in the .zwc  found on FPATH.  If I want the newer 
version
then I should source it.

> (**) "zcompile -c" can explode functions that are already in memory
> into multiple "files" that then go into the archive, but that's as
> close as it gets.
When I revisit this, I'll read your posts backwards.  This one is the 
one that would come first
in the HOWTO.  The first thing to understand is why, when and where we'd 
want to
use autoload.  What is it for?  Why did God make it on the seventh day?  
Then, it's
constraints and why they are what they are, then the implementation with 
examples.

Looking back, I've misunderstood the whole point of the thing.  Like the 
C-head
that I am, I'm thinking: 'What a good idea!  We can boil down our 
functions to
'.obj' files for faster loading, pack them together into one file for 
more speed yet, and
best of all, have them unloaded in memory until they are actually called 
at which time
they are 'autoloaded' automagically.  How elegant, I says to myself, 
it's like a .zip--all
compressed and packed together, and just as you can extract a single 
file from a .zip
so you can source a single function from a .zwc and zsh will even do it 
automatically
for you if you autoload that function cuz zsh will keep a table of where 
that
function is found and source it only when you call for the function.

It's all Sebastian's fault ;-)

Seriously sir, I exhaust your patience.  For now the one thing I know is 
that I don't
want to autoload anything, it's too obscure.