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 16:26:49 +0200 Message-ID: References: <0E94BE5F9874463D9B4C2A039A3C24E9@gmail.com> <87r4884gx6.fsf@yandex.ru> <52D7E096.8000101@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b3a814254545b04f01737f9 X-Trace: ger.gmane.org 1389882419 26520 80.91.229.3 (16 Jan 2014 14:26:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 16 Jan 2014 14:26:59 +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 15:27:06 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 1W3nuP-0004Ds-72 for ged-emacs-devel@m.gmane.org; Thu, 16 Jan 2014 15:27:01 +0100 Original-Received: from localhost ([::1]:32924 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3nuO-0001ul-FE for ged-emacs-devel@m.gmane.org; Thu, 16 Jan 2014 09:27:00 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:32802) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3nuK-0001to-6T for emacs-devel@gnu.org; Thu, 16 Jan 2014 09:26:57 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W3nuE-0001Ox-SF for emacs-devel@gnu.org; Thu, 16 Jan 2014 09:26:56 -0500 Original-Received: from mail-oa0-x22f.google.com ([2607:f8b0:4003:c02::22f]:55418) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3nuE-0001Ot-Ko for emacs-devel@gnu.org; Thu, 16 Jan 2014 09:26:50 -0500 Original-Received: by mail-oa0-f47.google.com with SMTP id m1so1726868oag.6 for ; Thu, 16 Jan 2014 06:26:50 -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=FkRqSp4X35i1upt6CW574NDp8Sl7y4RCNI9kaHxW+a8=; b=njiu4jIxnPUUCrjqudmEPegnG6kXpwdw7hYmWedmdRtOULtdspfj/NPSEH1Nz2AQU5 K56Fim0A1AAU1WpViTbftySLCo3vBUboo5/4JDfdr2W6UEPQy2rKYG84RzE1KUjeZxF6 aJWY0RAoVbmnUMJwGe55PQsE5cGW5xcuUao/sT1dVGC/8lQPCAVnpoPY1mScygbdatFi lD8t+cHK8h3KDXYHz6NfetiqsCJV3KFW20IpFtMYDwomPtXT7LJA9NPdg6Mc2dZYhriH 3MrGzBYzsF3gEI+de6mHyLtwB/ZV8VD2yaq+Cmv79mnbXhKYDifGMhMyW0yW+SzHllWQ tjfQ== X-Received: by 10.60.125.98 with SMTP id mp2mr383771oeb.86.1389882410028; Thu, 16 Jan 2014 06:26:50 -0800 (PST) Original-Received: by 10.76.79.102 with HTTP; Thu, 16 Jan 2014 06:26:49 -0800 (PST) In-Reply-To: <52D7E096.8000101@yandex.ru> X-Google-Sender-Auth: faT3HoyzfOaquQxZCbCLyyjiM1w X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4003:c02::22f 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:168531 Archived-At: --047d7b3a814254545b04f01737f9 Content-Type: text/plain; charset=UTF-8 On 16 January 2014 15:37, Dmitry Gutov wrote: > On 16.01.2014 12:15, Bozhidar Batsov wrote: > >> I'm OK with the patch, but it makes configuration a bit more difficult >> since users should actually know all the alignable keywords. >> > > Why? The Customize interface will still show all possible values, and if > the user looks at the definition of the variable directly, they should > notice the use of `ruby-alignable-keywords'. Fair enough, although in practice relatively few people use it. Anyways, this is a minor detail. > > > I guess we >> can mention `ruby-alignable-keywords' in the docstring >> of `ruby-align-to-stmt-keywords' and consider this a good enough hint >> for the users. One problem with the current implementation is that it >> won't play nice with assignments if you won't to treat them differently: >> > > Do you suggest to both apply the patch I suggested, *and* add a new user > option? Because without the patch, there won't be a way to treat them "the > same". 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. > > > What I'm saying is that some people >> might prefer to align `def` with a statement beginning only with access >> modifier methods. >> > > What I'd like to know if you personally plan to use such user option. > Adapting to a hypothetical user can wait until the release of 24.4, I'd > say. And it'd be better to wait until a specific feature request anyway. It depends on whether I'd have to use the result of an method definition in an assignment. :-) Seems unlikely at this point, since I don't have strong feelings about this. > > > > Of course, it seems unlikely that someone will assign > >> the value of a method def to a variable, but in the future a method >> definition in MRI, >> > > The above sentence seems to be missing something. Can't believe I wrote something as crazy as this. 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). > > > > but it makes sense in Rubinius for instance. > > Could you explain why? > In Rubinius defs have always returned an object: def foo; end => # I can assume that some people capture this object and manipulate it. 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. --047d7b3a814254545b04f01737f9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 1= 6 January 2014 15:37, Dmitry Gutov <dgutov@yandex.ru> wrote:<= br>
On 16.01.2014 12:15, Bozhidar Batsov wrote:
I'm OK with the patch, but it makes configuration a bit more difficult<= br> since users should actually know all the alignable keywords.

Why? The Customize interface will still show all possible values, and if th= e user looks at the definition of the variable directly, they should notice= the use of `ruby-alignable-keywords'.

Fair enough, although in practice relatively few people use it. Anyway= s, this is a minor detail.=C2=A0


I guess we
can mention `ruby-alignable-keywords' in the docstring
of `ruby-align-to-stmt-keywords' and consider this a good enough hint for the users. One problem with the current implementation is that it
won't play nice with assignments if you won't to treat them differe= ntly:

Do you suggest to both apply the patch I suggested, *and* add a new user op= tion? Because without the patch, there won't be a way to treat them &qu= ot;the same".

By "current impleme= ntation" I meant the current patch. Yeah, I think that some way to hav= e defs align to the start of an expression only for modifier expressions mi= ght be a good idea in the interest of maximum flexibility.
=C2=A0


What I'm saying is that some people
might prefer to align `def` with a statement beginning only with access
modifier methods.

What I'd like to know if you personally plan to use such user option. A= dapting to a hypothetical user can wait until the release of 24.4, I'd = say. And it'd be better to wait until a specific feature request anyway= .

It depends on whether I'd have to use the result of= an method definition in an assignment. :-) Seems unlikely at this point, s= ince I don't have strong feelings about this.
=C2=A0


> Of course, it seems unlikely that someone will assign
the value of a method def to a variable, but in the future a method
definition in MRI,

The above sentence seems to be missing something.

Can't believe I wrote something as crazy as this. I meant to say= that in the current implementation of the feature in MRI assigning the res= ult 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).= =C2=A0


> but it makes sense in Rubinius for instance.

Could you explain why?

In Rubinius defs= have always returned an object:

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

I can assume that some people capture this object and manipu= late it.

Anyways, I think that the current patch w= ill be good enough for most users. I was just pointing out some potential p= roblems in case they were overlooked by you. =C2=A0

--047d7b3a814254545b04f01737f9--