zsh-workers
 help / color / mirror / code / Atom feed
From: Zefram <zefram@fysh.org>
To: pws@pwstephenson.fsnet.co.uk (Peter Stephenson)
Cc: zsh-workers@sunsite.auc.dk
Subject: Re: PATCH: hierarchical module names
Date: Wed, 15 Dec 1999 10:52:15 +0000 (GMT)	[thread overview]
Message-ID: <E11yC2a-0004gD-00@crucigera.fysh.org> (raw)
In-Reply-To: <E11y1cO-0003fh-00.1999-12-14-23-44-33@mail1.svr.pol.co.uk> from Peter Stephenson at "Dec 14, 1999 11:45:32 pm"

Peter Stephenson wrote:
>I don't like this bit.  It means zmodload behaves differently from the way
>it's done for several years now.  I don't see why the main modules
>shouldn't keep their old names.

Ah, yes, there's another thing that got lost as the patch grew. I'd
intended to do some sort of backward compatibility, but hadn't decided
quite how to do it.

I think the old modules do need to keep their historical names, one way or
another.  But I don't see a problem with all new modules getting a prefix.
"zsh/", in particular, is not an onerous amount of extra typing.

>Or, if you prefer, you can make a name without a slash equivalent to the
>same with zsh/ stuck in front.  That might be the simplest.

This is a reasonable solution.  Three other solutions occur to me:

1. Have only the historically-established names be aliased.

2. Alias the historically-established names by filesystem links, so that
   the executable doesn't need to know about specific names.

3. Have alias modules for the historically-established names.  We'd have,
   for example, a `zle' module, which has a built-in dependency on
   `zsh/zle' but doesn't actually do anything itself.  So loading `zle'
   would have the effect of loading `zsh/zle', and zmodload would then
   report both `zle' and `zsh/zle' as loaded.

I favour solution 3.  It seems to maintain the greatest degree of
compatibility, while not requiring any changes to the mechanism.

>> * There is no way to load a module from a specified filename.  There
>>   should probably be a distinct option for this, if the capability is
>>   to exist at all.
>
>I don't think this is a worry; you can write a function with some $fpath
>trickery if you're desparate.

That's pretty much what I thought.  The only issue is what happens if
the module file has the `wrong' name, or is in a subdirectory with the
wrong name, for example, where it is compiled in the zsh build tree.
That's what the extra option would be for.

Possible technique: have zmodload check module name syntax at command-line
time, rather than at load time, and then extend the syntax to allow
<module-name>:<file-name> to specify loading a module from a specific
file.

-zefram


  reply	other threads:[~1999-12-15 10:52 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-12-14 17:07 zefram
1999-12-14 23:45 ` Peter Stephenson
1999-12-15 10:52   ` Zefram [this message]
1999-12-15 20:31     ` Peter Stephenson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E11yC2a-0004gD-00@crucigera.fysh.org \
    --to=zefram@fysh.org \
    --cc=pws@pwstephenson.fsnet.co.uk \
    --cc=zsh-workers@sunsite.auc.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).