From: Bart Schaefer <schaefer@brasslantern.com>
To: Felipe Contreras <felipe.contreras@gmail.com>
Cc: Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: One possible answer to typeset vs. unset
Date: Fri, 4 Dec 2020 07:49:54 -0800 [thread overview]
Message-ID: <CAH+w=7YxvpfjxCP9i9fHSfu0TWXpiCqXrmLkiVDDiDjZWLC8xQ@mail.gmail.com> (raw)
In-Reply-To: <CAMP44s3y2zqbG=8Zxqmn5RcwHC-CF2VaiwADhUbj2AokRKndkA@mail.gmail.com>
On Fri, Dec 4, 2020 at 3:04 AM Felipe Contreras
<felipe.contreras@gmail.com> wrote:
>
> On Thu, Dec 3, 2020 at 3:19 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
> >
> > I looked at this for a while yesterday evening. My conclusion is that
> > tied variables are already a bit of a hack.
Part of my latest commit log on the declarednull branch:
The scalar struct param of a tied pair stores a direct pointer to the
internal array value of the array struct param, and upon assignment
modifies it without referring to the containing struct. This means
that there's no opportunity to clear the PM_DECLAREDNULL bits on both
structs when the scalar is assigned. Conversely, assigning to the
array does use the struct for the scalar.
I think this can be fixed but I don't want it to become inefficient.
OTOH, tied parameters (other than specials, which are different in
several ways) may not be used (or updated when they are) very much.
> > Consequently I don't know if your patch would cause a different test
> > for unset-ness (that hasn't been written yet) to fail, but something
> > like that patch may be unavoidable.
>
> I can't parse that. What would such unset-ness test do?
Check that both elements of the pair appear to be unset when neither
has been initialized.
As it currently stands on the branch, following
typeset -T TIED_SCALAR tied_array
These
typeset -p TIED_SCALAR
typeset -p tied_array
print differing initializers.
next prev parent reply other threads:[~2020-12-04 15:50 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-28 19:49 Bart Schaefer
2020-11-28 20:00 ` Bart Schaefer
2020-11-28 20:21 ` Bart Schaefer
2020-12-01 8:54 ` Felipe Contreras
2020-12-03 21:19 ` Bart Schaefer
2020-12-04 11:04 ` Felipe Contreras
2020-12-04 15:49 ` Bart Schaefer [this message]
2020-12-04 19:47 ` Bart Schaefer
2020-12-05 0:22 ` Bart Schaefer
2020-12-05 0:28 ` Bart Schaefer
2020-12-05 0:51 ` Bart Schaefer
2020-12-05 22:17 ` Bart Schaefer
2020-12-23 23:00 ` Felipe Contreras
2020-12-02 17:18 ` Vincent Lefevre
2020-12-02 18:03 ` Bart Schaefer
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='CAH+w=7YxvpfjxCP9i9fHSfu0TWXpiCqXrmLkiVDDiDjZWLC8xQ@mail.gmail.com' \
--to=schaefer@brasslantern.com \
--cc=felipe.contreras@gmail.com \
--cc=zsh-workers@zsh.org \
/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).