From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Bozhidar Batsov Newsgroups: gmane.emacs.devel Subject: Re: Obsoleting hash-table-* functions in subr-x in favor of map-* functions Date: Mon, 22 Jun 2015 08:43:56 +0300 Message-ID: References: <87h9q0ga81.fsf@petton.fr> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11342c2c7a7610051914c29b X-Trace: ger.gmane.org 1434951847 15999 80.91.229.3 (22 Jun 2015 05:44:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 22 Jun 2015 05:44:07 +0000 (UTC) Cc: emacs-devel To: Nicolas Petton Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 22 07:44:07 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Z6uWa-0006od-Mw for ged-emacs-devel@m.gmane.org; Mon, 22 Jun 2015 07:44:04 +0200 Original-Received: from localhost ([::1]:38264 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z6uWZ-00056P-VK for ged-emacs-devel@m.gmane.org; Mon, 22 Jun 2015 01:44:03 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55249) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z6uWW-000560-4E for emacs-devel@gnu.org; Mon, 22 Jun 2015 01:44:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z6uWT-0001DY-Iu for emacs-devel@gnu.org; Mon, 22 Jun 2015 01:44:00 -0400 Original-Received: from mail-la0-x22a.google.com ([2a00:1450:4010:c03::22a]:35508) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z6uWT-0001Cj-B0 for emacs-devel@gnu.org; Mon, 22 Jun 2015 01:43:57 -0400 Original-Received: by lagi2 with SMTP id i2so13417122lag.2 for ; Sun, 21 Jun 2015 22:43:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=X6MOcIwP1AyirZwt7mfB2QKw1avyGcaZb/zec9hQ8Mo=; b=srACUH/rIe4i5q2YBjdCVecYdlfXOwHN7jHBFZ0BlOHoptQDEL7ZoZYmLT/vunxgOr csgnfwfAQjs2qUY9QbTVXPAiaFnZp3gDt0obuTM3xN1DgYWUyCYE1az7jSe/5WVMKJdC Vw5qdtH9QERTwRCDKsuNPFD9Vctk16Y2NnuId7/bTBTeDSt3+0reCuZZ4AAC5FPE8Sjs M7AbYqjAB8xI1UoAI0L7SP6oeJWSvA8g3IaPr8djCkJiUplGQJzrvMZKOrDQp2MzVOV+ Ur+br3FXm8+1D24aFPVdcaINFr3kkvNl4AUjBQIUK3WkVrQz20euJMKExoi9zVJfXzwG 7UkQ== X-Received: by 10.152.243.9 with SMTP id wu9mr27937461lac.63.1434951836394; Sun, 21 Jun 2015 22:43:56 -0700 (PDT) Original-Received: by 10.112.172.164 with HTTP; Sun, 21 Jun 2015 22:43:56 -0700 (PDT) In-Reply-To: X-Google-Sender-Auth: QzvXItg1tVJLZ8ZydzC4zte23Ro X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c03::22a X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:187365 Archived-At: --001a11342c2c7a7610051914c29b Content-Type: text/plain; charset=UTF-8 P.S. I'm aware this was borrowed from the likes of Clojure (as was seq), but sometimes it's not a great idea to bring in external terminology 1:1. Anyways, that's not major. When I added those hash-table specific function the point was to extend a specific API, not to look for some generic solution. On 22 June 2015 at 08:28, Bozhidar Batsov wrote: > Sounds a bit strange to me. Those are somewhat basic hash-table-specific > stuff. If you're going to obsolete them, why not obsolete everything except > hash-table constructors? Somewhere a line has to be drawn. > > Btw, I'm still not sure about the "map" naming, as this is a term that's > not used at all in Emacs Lisp terminology and will be the source of a lot > of confusing I guess. > > On 21 June 2015 at 21:58, Nicolas Petton wrote: > >> Hi, >> >> I'm thinking about obsoleting `hash-table-empty-p', `hash-table-keys' >> and `hash-table-values' defined in subr-x in favor of their map-* >> equivalent. >> >> WDYT? >> >> Cheers, >> Nico >> -- >> Nicolas Petton >> http://nicolas-petton.fr >> > > --001a11342c2c7a7610051914c29b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
P.S. I'm aware this was borrowed from the likes of Clo= jure (as was seq), but sometimes it's not a great idea to bring in exte= rnal terminology 1:1. Anyways, that's not major. When I added those has= h-table specific function the point was to extend a specific API, not to lo= ok for some generic solution.=C2=A0

On 22 June 2015 at 08:28, Bozhidar Batsov <bozhi= dar@batsov.com> wrote:
Sounds a bit strange to me. Those are somewhat basic hash-tabl= e-specific stuff. If you're going to obsolete them, why not obsolete ev= erything except hash-table constructors? Somewhere a line has to be drawn.= =C2=A0

Btw, I'm still not sure about the "map&q= uot; naming, as this is a term that's not used at all in Emacs Lisp ter= minology and will be the source of a lot of confusing I guess.
<= div class=3D"HOEnZb">

On 21 June 2015 at 21:58, Nicolas Petton <nicolas@pe= tton.fr> wrote:
Hi,

I'm thinking about obsoleting `hash-table-empty-p', `hash-table-key= s'
and `hash-table-values' defined in subr-x in favor of their map-*
equivalent.

WDYT?

Cheers,
Nico
--
Nicolas Petton
h= ttp://nicolas-petton.fr


--001a11342c2c7a7610051914c29b--