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

[Bozhidar Batsov]

On 16 January 2014 15:37, Dmitry Gutov <address@hidden> 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.