From: Bozhidar Batsov <bozhidar@batsov.com>
To: Dmitry Gutov <dgutov@yandex.ru>
Cc: Stefan Monnier <monnier@iro.umontreal.ca>,
emacs-devel <emacs-devel@gnu.org>
Subject: Re: [ruby-mode] Private/protected method definition layout in Ruby 2.1
Date: Thu, 16 Jan 2014 16:26:49 +0200 [thread overview]
Message-ID: <CAM9Zgm0OZ5=n2f44=T9YZiRTyH3O5U5yWwAd8kSpJ1VftWDhYg@mail.gmail.com> (raw)
In-Reply-To: <52D7E096.8000101@yandex.ru>
[-- Attachment #1: Type: text/plain, Size: 2710 bytes --]
On 16 January 2014 15:37, Dmitry Gutov <dgutov@yandex.ru> 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
=> #<Rubinius::CompiledMethod foo file=(irb)>
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.
[-- Attachment #2: Type: text/html, Size: 4976 bytes --]
next prev parent reply other threads:[~2014-01-16 14:26 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-15 14:41 [ruby-mode] Private/protected method definition layout in Ruby 2.1 Bozhidar Batsov
2014-01-15 16:24 ` Stefan Monnier
2014-01-15 18:18 ` Dmitry Gutov
2014-01-15 18:51 ` Stefan Monnier
2014-01-16 5:47 ` Dmitry Gutov
2014-01-16 10:15 ` Bozhidar Batsov
2014-01-16 13:37 ` Dmitry Gutov
2014-01-16 14:26 ` Bozhidar Batsov [this message]
2014-01-16 18:40 ` Dmitry Gutov
2014-01-16 19:38 ` Bozhidar Batsov
2014-01-17 3:17 ` Dmitry Gutov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAM9Zgm0OZ5=n2f44=T9YZiRTyH3O5U5yWwAd8kSpJ1VftWDhYg@mail.gmail.com' \
--to=bozhidar@batsov.com \
--cc=dgutov@yandex.ru \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.