Re: [ruby-mode] Private/protected method definition layout in Ruby 2.1

[Bozhidar Batsov <bozhidar@batsov.com>]

[-- 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 --]