zsh-workers
 help / color / mirror / code / Atom feed
From: Zefram <zefram@fysh.org>
To: Peter Stephenson <pws@pwstephenson.fsnet.co.uk>
Cc: zsh-workers@sunsite.auc.dk
Subject: Re: PATCH: alias modules
Date: Tue, 21 Dec 1999 10:54:31 +0000 (GMT)	[thread overview]
Message-ID: <E120Mw3-00004s-00@crucigera.fysh.org> (raw)
In-Reply-To: <E120BBn-00065n-00.1999-12-20-22-21-59@mail2.svr.pol.co.uk> from Peter Stephenson at "Dec 20, 1999 10:23:14 pm"

Peter Stephenson wrote:
>any reason you haven't done this the way I suggested, which would have put
>aliasing under user control,

We don't want aliasing under user control.  My view is that aliases are
for backward compatibility only.

The point of hierarchical module names is that each module can
have a canonical global name, and users loading modules can specify
unambiguously which module they want.  To do that, the user has to give
the fully-qualified module name at some point.  And since modules are
usually (auto)loaded in initialisation files anyway, there's no typing
saved by letting the user set up an abbreviated name.

But really the reason why I did it this way is that it seems neater.
It's adding no new semantics, just using the existing infrastructure
(module dependencies).  zsh has far too much semi-hidden state as it
is; it's time we started using its existing capabilities to their full
potential, rather than doing each new thing in C.  The new completion
system is heading that way, much to my delight.

>                             would have allowed zmodload to show up aliases
>clearly

zmodload -d

OK, this makes no distinction between alias modules and other
dependencies.  But OTOH, I don't think we want to treat straight aliases
specially.  What if we split a module into several: with this system, we
can make the old name an empty module depending on all the new modules,
and it is treated exactly like the 1-to-1 aliases.

>                                    and wouldn't have filled the place up
>with bogus modules (some 30k each here)?

Oh.  They're 3620 bytes each here, and I assumed they'd be small
everywhere, since they contain almost no code.  But as I explained
earlier, my intention is that there won't eventually be so many.  3.1.7
should contain aliases only for those modules that existed in 3.1.6,
and we should consider at some point which modules are really important
enough to warrant backward compatibility with the old names.

-zefram


  reply	other threads:[~1999-12-21 10:54 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-12-16 13:32 zefram
1999-12-20 22:23 ` Peter Stephenson
1999-12-21 10:54   ` Zefram [this message]
1999-12-21 22:37     ` Peter Stephenson
1999-12-22 13:20       ` Zefram

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=E120Mw3-00004s-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).