[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: terminology
From: |
Bruno Haible |
Subject: |
Re: terminology |
Date: |
Sun, 11 Oct 2020 16:14:38 +0200 |
User-agent: |
KMail/5.1.3 (Linux/4.4.0-189-generic; KDE/5.18.0; x86_64; ; ) |
Hi Marc,
> I have attached an improved version of the HAMT module to this email.
How about terminology: "delete" vs. "remove"?
In C++ the verb "delete" is more or less the same as "free": It means
"deallocate" and "free memory".
Likewise in some C APIs, e.g. pthread_key_delete.
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".
Yes, we still have hash_delete (in module 'hash') and 'argz_delete' (in
module 'argz'); these are very old modules.
Bruno
[1] https://docs.oracle.com/javase/7/docs/api/java/util/Set.html
[2]
https://docs.microsoft.com/en-us/dotnet/api/system.collections.generic.hashset-1
[3] https://docs.python.org/3/library/stdtypes.html#set
- Re: out-of-memory handling, (continued)
- 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 <=
- Re: terminology, Marc Nieper-Wißkirchen, 2020/10/11
- Re: _Atomic, Bruno Haible, 2020/10/10
- Re: _Atomic, Paul Eggert, 2020/10/11
- Re: _Atomic, Bruno Haible, 2020/10/11