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: [ruby-mode] Private/protected method definition layout in Ruby 2.1 Date: Thu, 16 Jan 2014 21:38:28 +0200 Message-ID: References: <0E94BE5F9874463D9B4C2A039A3C24E9@gmail.com> <87r4884gx6.fsf@yandex.ru> <52D7E096.8000101@yandex.ru> <52D82799.9000408@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b33d3cedcf7cf04f01b919a X-Trace: ger.gmane.org 1389901114 6810 80.91.229.3 (16 Jan 2014 19:38:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 16 Jan 2014 19:38:34 +0000 (UTC) Cc: Stefan Monnier , emacs-devel To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 16 20:38:41 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 1W3sm0-0000rm-P8 for ged-emacs-devel@m.gmane.org; Thu, 16 Jan 2014 20:38:40 +0100 Original-Received: from localhost ([::1]:34691 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3sm0-0002jc-DJ for ged-emacs-devel@m.gmane.org; Thu, 16 Jan 2014 14:38:40 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33110) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3sls-0002cp-JA for emacs-devel@gnu.org; Thu, 16 Jan 2014 14:38:37 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W3slr-0005CZ-1O for emacs-devel@gnu.org; Thu, 16 Jan 2014 14:38:32 -0500 Original-Received: from mail-oa0-x234.google.com ([2607:f8b0:4003:c02::234]:49389) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3slq-0005BQ-Cj for emacs-devel@gnu.org; Thu, 16 Jan 2014 14:38:30 -0500 Original-Received: by mail-oa0-f52.google.com with SMTP id o6so3433265oag.39 for ; Thu, 16 Jan 2014 11:38:28 -0800 (PST) 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=YAiS9kHbcm9UBB0edAXdjik+legZcgbuOwn7fD4pVQs=; b=zIpgyp7eJYA2zw/ldfl4dZawBQyaWpj/toensosIzYv6GorPvJO3roQVwuNDp9eXh9 TzKwnswrmEv68NZzmAIKj4mHLznyz2h8KThAZXAqV4MWPsEOilXM7C/UuG6KGqcVDWsO o9on8aatr3B7hmbYPJ08z/zC+VuG0Y9P0Td/P/j5w1D8EwfLHv62d+hAYOYIf0jhDZ1/ qvvZ5gjOZoK0nZyDH5sR2miO0sjqK+25J2cuCEPZVydZh6P+SSqPjsUl/FjHOM0myQB9 JGUFXLAM7qKNBCExNBfaJY+UtNr3dAMrbJykCWEiBX0aUqVxXbDChnAqlZkiYr5mbmUQ +nZg== X-Received: by 10.60.93.229 with SMTP id cx5mr2104690oeb.82.1389901108801; Thu, 16 Jan 2014 11:38:28 -0800 (PST) Original-Received: by 10.76.79.102 with HTTP; Thu, 16 Jan 2014 11:38:28 -0800 (PST) In-Reply-To: <52D82799.9000408@yandex.ru> X-Google-Sender-Auth: LwTYWJEPrj6lNsWq-nmErgi2nxk X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4003:c02::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:168571 Archived-At: --047d7b33d3cedcf7cf04f01b919a Content-Type: text/plain; charset=UTF-8 One thing I've learned from maintaining open-source projects is that someone will always be unhappy no matter what you do. :-) The patch you've suggested improves upon the current state of the code and add extra flexibility, so we probably shouldn't dwell too much over the details in it and simply install it. On 16 January 2014 20:40, Dmitry Gutov wrote: > 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. > --047d7b33d3cedcf7cf04f01b919a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
One thing I've learned from maintaining open-source pr= ojects is that someone will always be unhappy no matter what you do. :-) Th= e patch you've suggested
improves upon the current state of the cod= e and add extra flexibility, so we probably shouldn't dwell too much ov= er the details in it and simply install it.=C2=A0


On 16 J= anuary 2014 20:40, Dmitry Gutov <dgutov@yandex.ru> wrote:
=
On 16.01.2014 16:26, Bozhidar Batsov wrote:
By "current implementation" I meant the current patch. Yeah, I th= ink
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 w= as undefined. Now that it's specified to be method name symbol, it prob= ably won't ever change, in the interests of backward compatibility.

In Rubinius defs have always returned an object:

def foo; end
=3D> #<Rubinius::CompiledMethod foo file=3D(irb)>

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.

--047d7b33d3cedcf7cf04f01b919a--