From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: [ruby-mode] Private/protected method definition layout in Ruby 2.1 Date: Thu, 16 Jan 2014 20:40:25 +0200 Message-ID: <52D82799.9000408@yandex.ru> References: <0E94BE5F9874463D9B4C2A039A3C24E9@gmail.com> <87r4884gx6.fsf@yandex.ru> <52D7E096.8000101@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1389897646 28696 80.91.229.3 (16 Jan 2014 18:40:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 16 Jan 2014 18:40:46 +0000 (UTC) Cc: Stefan Monnier , emacs-devel To: Bozhidar Batsov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 16 19:40:51 2014 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 1W3rs3-0001Do-3X for ged-emacs-devel@m.gmane.org; Thu, 16 Jan 2014 19:40:51 +0100 Original-Received: from localhost ([::1]:34515 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3rs2-0004aP-O5 for ged-emacs-devel@m.gmane.org; Thu, 16 Jan 2014 13:40:50 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48738) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3rrr-0004a8-D1 for emacs-devel@gnu.org; Thu, 16 Jan 2014 13:40:47 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W3rri-0003gQ-P3 for emacs-devel@gnu.org; Thu, 16 Jan 2014 13:40:39 -0500 Original-Received: from mail-ea0-x234.google.com ([2a00:1450:4013:c01::234]:32840) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3rri-0003fy-B3 for emacs-devel@gnu.org; Thu, 16 Jan 2014 13:40:30 -0500 Original-Received: by mail-ea0-f180.google.com with SMTP id f15so1323016eak.11 for ; Thu, 16 Jan 2014 10:40:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=GjhtGTCRqGj2GmbiE9Jk8fFZPt/D5i38TZyduUcFNqM=; b=QN1WxWF2e7WPWqoN41f1rswBIu28D+EQCvFM8l/s7t30PTLHkJwFRGsg1V0SwCkvFK zEGCzDel4ihzZX3aNa0Hez74ncLwi6ZPdnN5gotT6PQWUKJoqZa2sDOD0WJ9aznJxjuQ 8FMPQYdb+Rk39K/VJwHrHW594JH7227GUQ2pActoc9n7N6KJi851JywZKMHkHqZ6GPh+ 3fGl3+kuA7jEGSFeHx77VnlpfR694QqfKHu+UsRjCTCUZ0djJfuV7LIj/If0N4cQGK+3 iGIylK2TeJ00ZjGjIzckuSQWHU1iE7AFVVjrZm9yPVkt8w9k6FwohWfdjAiydXSAn5iV mhpA== X-Received: by 10.14.246.202 with SMTP id q50mr14278619eer.58.1389897629249; Thu, 16 Jan 2014 10:40:29 -0800 (PST) Original-Received: from [192.168.0.94] (static-nbl2-118.cytanet.com.cy. [212.31.107.118]) by mx.google.com with ESMTPSA id v7sm20376203eel.2.2014.01.16.10.40.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 16 Jan 2014 10:40:28 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4013:c01::234 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:168562 Archived-At: On 16.01.2014 16:26, Bozhidar Batsov wrote: > By "current implementation" I meant the current patch. Yeah, I think > that some way to have defs align to the start of an expression only for > modifier expressions might be a good idea in the interest of maximum > flexibility. They are plain method calls anyway. Like mentioned, `private', etc, are not keywords. > I meant to say that in > the current implementation of the feature in MRI assigning the result to > a variable doesn't make much sense, but in the future that might change > (if the return value becomes a method object instead of a symbol). I don't think it's likely to change. Previously, the return value was undefined. Now that it's specified to be method name symbol, it probably won't ever change, in the interests of backward compatibility. > In Rubinius defs have always returned an object: > > def foo; end > => # Ah, I see. It's probably considered an implementation detail, though. > Anyways, I think that the current patch will be good enough for most > users. I was just pointing out some potential problems in case they were > overlooked by you. Thanks, but the occasional need for more flexibility is often apparent. The question I'm usually trying to answer is whether we can get away with fewer options, and still keep users happy.