Mirror of forum.nim-lang.org

5499 :: ``Table.take`` should be ``Table.pop`` -- discuss

• cblake (orginal) [2019-11-13T14:47:22+01:00] view original

  Before we leave things as just take in Table-land for very long/a full release cycle and having to worry about backward compatibility, I thought this warranted a much wider discussion than a comment thread in a closed pull request:

  https://github.com/nim-lang/Nim/pull/12600

  Also relevant side question should pop be added to apis.rst? My opinions are in the link, but others should chime in.

  This might also be of broader interest to relate to "rapid stdlib retractions in the Nim 1.0 era" if we did want to just rename rather than deprecate the brand new take overloads.

---

• Araq (orginal) [2019-11-13T17:28:21+01:00] view original

  I don't mind pop instead of take (though "take" is the better word IMO) but I'm personally quite tired of "X is inconsistent with Y so let's deprecate X because nobody ever got tired of applying random changes to existing codebases".

---

• kaushalmodi (orginal) [2019-11-13T17:51:01+01:00] view original

  +1 for pop.

---

• mratsim (orginal) [2019-11-13T18:09:22+01:00] view original

  +1.

  Is it me or the apis.rst has a completely broken format on Github? https://github.com/nim-lang/Nim/blob/devel/doc/apis.rst

---

• cblake (orginal) [2019-11-15T07:54:02+01:00] view original

  @mratsim - it's not just you. Formatting looks pretty garbled.

  @araq - sensible to me to duplicate/alias rather than deprecate. Pretty low-cost.

---

• spip (orginal) [2019-11-16T17:08:55+01:00] view original

  As proc name overloading is one of the ways to offer genericity in Nim code, selecting the right name is important, particularly for data structures that share similar behaviours. Some languages have symbol renaming or aliasing, like Eiffel, to handle such cases of semantic similarity.

  +1 for pop

---

• cblake (orginal) [2019-11-17T14:56:55+01:00] view original

  Ok. Just to close the loop on this thread I believe this accommodates all expressed views: https://github.com/nim-lang/Nim/pull/12678 (except maybe one week pre-release implies backward compatibility forever view or the if one-table has a proc, all tables should have the proc view, but people didn't seem to comment on/care much about that aspect of this question).

---

• Araq (orginal) [2019-12-01T07:52:30+01:00] view original

  But then we also need mpop "for consistency", it never ends...

---

• mratsim (orginal) [2019-12-01T10:50:47+01:00] view original

  Why mpop, the caller takes ownership of the result and must assign it or discard it.

---

• Araq (orginal) [2019-12-01T12:00:20+01:00] view original

  Lol good point, I shouldn't post here when I had too little sleep.

---

• cblake (orginal) [2019-12-01T19:21:09+01:00] view original

  An un-keyed pop(Table): tuple[K,V] more similar to HashSet.pop is mentioned in the PR commentary linked above. (I would personally just use the already-defined iterator than b3liever's inline expansion, but eh. Either way.) Totally suitable for another PR. I just wanted to keep the above one more focused.

---