[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: terminology
From: |
Marc Nieper-Wißkirchen |
Subject: |
Re: terminology |
Date: |
Sun, 11 Oct 2020 16:20:17 +0200 |
Am So., 11. Okt. 2020 um 16:14 Uhr schrieb Bruno Haible <bruno@clisp.org>:
>
> Hi Marc,
>
> > I have attached an improved version of the HAMT module to this email.
>
> How about terminology: "delete" vs. "remove"?
> In this sense, 'hamt_delete' is triggering the wrong associations.
> How about renaming 'hamt_remove'?
>
> Deleting an entry from a hash table or HAMT does not always mean to
> delete the object that the entry references.
>
> The Java collections [1], C# collections [2], Python collections [3]
> all use the verb "remove".
I'm fine with this change and agree with your reasoning. I used the
hash module (see your comment below) as a guide for the interface,
that's why I called the procedure hamt_delete in the first place.
> Yes, we still have hash_delete (in module 'hash') and 'argz_delete' (in
> module 'argz'); these are very old modules.
Marc
- Re: HAMT for gl_set and gl_map, (continued)
- Re: HAMT for gl_set and gl_map, Bruno Haible, 2020/10/11
- Re: [New module] Persistent Hash Array Mapped Tries (HAMTs), Marc Nieper-Wißkirchen, 2020/10/11
- Re: Draft #3 (with iterators), Marc Nieper-Wißkirchen, 2020/10/11
- Re: Draft #3 (with iterators), Bruno Haible, 2020/10/11
- Re: Non-opaque hamt type?, Marc Nieper-Wißkirchen, 2020/10/12
- Re: Non-opaque hamt type?, Bruno Haible, 2020/10/18
- Re: Non-opaque hamt type?, Marc Nieper-Wißkirchen, 2020/10/18
- Re: Non-opaque hamt type?, Bruno Haible, 2020/10/18
- Re: Non-opaque hamt type?, Marc Nieper-Wißkirchen, 2020/10/18
- Re: terminology, Bruno Haible, 2020/10/11
- Re: terminology,
Marc Nieper-Wißkirchen <=
- Re: _Atomic, Bruno Haible, 2020/10/10
- Re: _Atomic, Paul Eggert, 2020/10/11
- Re: _Atomic, Bruno Haible, 2020/10/11