Re: Module hierarchies, aliasing, and dependencies

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

On Sep 14,  7:18pm, Andrej Borsenkow wrote:
}
} > On Sep 10, 10:35pm, Zefram wrote:
} > }
} > } [E.g.] zsh/deltochar depends on zsh/zle: with dependencies set up
} > } right, zsh/zle will be loaded automatically before zsh/deltochar.
} > } But if you load zsh/deltochar under the name "local/deltochar" (or
} > } just "deltochar", or anything else) zsh/zle won't be loaded first,
} > } and so the load will fail (unless zsh/zle was already loaded).
} >
} > I don't think this is really a problem -- the issue is not
} > automatically discovering that local/deltochar depends on zsh/zle,
} > it's discovering that local/zle has already substituted for zsh/zle
} > when loading zsh/deltochar.
}
} It looks, like both posters still assume that "file name" == "module
} name".  I do not see why it must be so.

It was not my intention to imply that "file name" == "module name" --
though I think the problems you point out with Cygwin may be a reason to
keep the ${filename:t} == ${modulename:t} behavior for at least a while
yet.

It *was* my assumption that the file name relative to $module_path would
be the single argument to zmodload when loading the module, but of course
there's no particular reason to assume that, either.

} zmodload -f /path/to/my/module.so zsh/zle

That would be fine, except that it requires you to know the full path
to the module and the shared object extension, so it won't work in a
cross-platform way.  How about instead something like

zmodload -N zsh/zle my/module

or perhaps

zmodload -N zsh/zle=my/module

which would mean the same as your suggestion, except that /path/to would
have to be added to $module_path.  (-N for "name as", roughly.)

This could interact with the alias mechanism, so that if you wrote:

zmodload -A zle=zsh/zle
zmodload -N zsh/zle=my/module
zmodload zle

Then it would load the file $^module_path/my/module(.so)(N) and enter the
string "zsh/zle" in the list of loaded modules.

} Of course, zmodload must check, that /path/to/my/module.so really
} defines zsh/zle, but after that no changes are really needed to
} current module system (but see below). So, what is needed
}
} - add some module identification (this may be one more entry point -
} it is probably the only way to do it, unless we want to reimplement
} runtime loader).
} 
} - separate module name and file name. Hey! we could even implement
} files that define more than one module! :-)

I suggest that, for the first pass, the "module identification" can be
limited to the base name of the shared object; unless I misunderstand
what you said about Windows DLLs, it won't work to load two DLLs with
the same base name anyway (at least not without a major rewrite, and
maybe not even then).

This means that we don't entirely separate the module name and the file
name, but we at least separate the module name from its load path.

} > An alternate solution has just occurred to me ... in the setup function in
} > local/zle, one could simply scan the module list for any module that has a
} > dependency on zsh/zle, and substitute the name local/zle in its place.
} 
} Unless I'm mistaken, this is completely redundant. The initial wish was to
} load the *same* module from different place, not to load module under
} different name?

The initial wish was to load the module from a different place and have
the "same name" part be automatically computed after the fact.  I've no
problem with giving up the automatic part for a simpler implementation.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net