From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daiki Ueno Newsgroups: gmane.emacs.devel Subject: Re: secure plist store Date: Fri, 01 Jul 2011 07:18:23 +0900 Message-ID: <87y60jvu8g.fsf-ueno@unixuser.org> References: <87sjrttwh8.fsf@lifelogs.com> <87wrh4b9h9.fsf@lifelogs.com> <87aae05l8p.fsf-ueno@unixuser.org> <87k4d4b66p.fsf@lifelogs.com> <87wrh0fh4g.fsf_-_@lifelogs.com> <87y60ncma8.fsf_-_@lifelogs.com> <87vcvrne02.fsf-ueno@unixuser.org> <87r56ep3sm.fsf@lifelogs.com> <874o39n171.fsf-ueno@unixuser.org> <87boxgr9f9.fsf@lifelogs.com> <87sjqry0it.fsf@lifelogs.com> <877h83xwoo.fsf-ueno@unixuser.org> <87oc1fv075.fsf@lifelogs.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1309472339 2131 80.91.229.12 (30 Jun 2011 22:18:59 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 30 Jun 2011 22:18:59 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 01 00:18:52 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QcPZT-0001ru-Vj for ged-emacs-devel@m.gmane.org; Fri, 01 Jul 2011 00:18:52 +0200 Original-Received: from localhost ([::1]:43063 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QcPZT-0000CL-3G for ged-emacs-devel@m.gmane.org; Thu, 30 Jun 2011 18:18:51 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:42891) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QcPZB-0000Bq-0f for emacs-devel@gnu.org; Thu, 30 Jun 2011 18:18:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QcPZ9-00086y-9M for emacs-devel@gnu.org; Thu, 30 Jun 2011 18:18:32 -0400 Original-Received: from ivory4.scn-net.ne.jp ([219.117.176.192]:38111) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1QcPZ8-00086V-Gj for emacs-devel@gnu.org; Thu, 30 Jun 2011 18:18:30 -0400 Original-Received: from ([192.168.0.187]) (envelope sender: ) by ivory4.scn-net.ne.jp with Active!Hunter esmtp server; Fri, 1 Jul 2011 07:18:24 +0900 Original-Received: Received: from well-done.deisui.org (g187018.scn-net.ne.jp [202.83.187.18]) (authenticated) by blue17.scn-net.ne.jp (unknown) with ESMTP id p5UMIOGJ008928 for ; Fri, 1 Jul 2011 07:18:24 +0900 In-Reply-To: <87oc1fv075.fsf@lifelogs.com> (Ted Zlatanov's message of "Thu, 30 Jun 2011 09:54:54 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-Received-From: 219.117.176.192 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:141290 Archived-At: Ted Zlatanov writes: > They are used. See the backend filtering in `auth-source-search' > coupled with `auth-source-backend-parse-parameters'. When you specify a > simple string as an auth-source, the host, port, and user are nil (so > that backend instance applies to every host, port, and user). I'm now confused about that, while those members are set in auth-source-backend-parse-parameters, they are not referred from any code in auth-source.el. Am I missing something (I tried M-x occur oref and slot-value)? > DU> Frankly I don't see any reason to use defclass here - why not using > DU> CLOS inheritance if you want to define members specific to some > DU> class derived from auth-source-backend (I mean host/port/user are > DU> only valuable for Secrets API backend)? > > For this case, EIEIO worked better for me. I've found some issues with > it, but overall it's a nice system that covers a lot of ground that > CLOS does not. I meant EIEIO with "CLOS". From the EIEIO doc: EIEIO ("Enhanced Implementation of Emacs Interpreted Objects") is a CLOS (Common Lisp Object System) compatibility layer for Emacs Lisp. I was really confused about auth-source.el usage of EIEIO, where defclass is only used as defstruct. It looks simply overkill such a purpose and misleading. Regards, -- Daiki Ueno