Project

General

Profile

Actions

Feature #7055

closed

Allow `.foo=` as a synonym of `self.foo=`

Added by alexeymuranov (Alexey Muranov) over 11 years ago. Updated over 11 years ago.

Status:
Rejected
Assignee:
-
Target version:
-
[ruby-core:47657]

Description

=begin
I propose to make the use of self in method calls optional:

.foo = 'bar'

instead of

self.foo = 'bar'

This only matters of course for assignment methods, to distinguish a method call from creating or setting a local variable.
=end

Updated by Eregon (Benoit Daloze) over 11 years ago

It would collide with existing notation:

h = {}
.default = 3

p h # => 3

A dot beginning a line in 1.9 uses the previous statement as a receiver.

Updated by alexeymuranov (Alexey Muranov) over 11 years ago

Thanks, I didn't know about this!

However, this use of a beginning dot does not excite me: it does not just use the previous statement value as the receiver, it in fact continues the previous line, which can also be done by leaving the dot on the previous line.

This makes it not clear if a line is over, and is not usable in IRB.

It would make more sense to me if a call with "empty receiver" always used either the value returned by the previous line, or the previously returned expression value, as the receiver:

'aa.bbb.cccc'.split('.')
prefix, suffix = .first, .last # => ['aa', 'cccc']

or

'aa.bbb.cccc'.split('.')
prefix, prefix_length = .first, .length # => ['aa', 2]

Well, this is not the original proposal anymore, i didn't mean to ask to deprecate the existing behavior. I am still interested in other opinions.

Updated by Eregon (Benoit Daloze) over 11 years ago

alexeymuranov (Alexey Muranov) wrote:

[...] it does not just use the previous statement value as the receiver, it in fact continues the previous line, which can also be done by leaving the dot on the previous line.

Yes, indeed, my wording was badly chosen.

alexeymuranov (Alexey Muranov) wrote:

I am still interested in other opinions.

I think a nicer syntax for setters would be worth adding, but it probably can't be ".setter =".

Updated by Eregon (Benoit Daloze) over 11 years ago

... although I guess there is no real use-case for the continuing dot with a method ending with "=", so it might be possible to distinguish them.

Updated by alexeymuranov (Alexey Muranov) over 11 years ago

I've thought a bit more about this, and in my opinion, using the "empty dot" to continue the previous line is a waste of notation.

Updated by marcandre (Marc-Andre Lafortune) over 11 years ago

  • Status changed from Open to Rejected

Closing this suggestion, as this would be a compatibility nightmare.

Updated by alexeymuranov (Alexey Muranov) over 11 years ago

Maybe then @ instead of self?

@.foo = 'bar'

instead of

self.foo = 'bar'

Updated by stomar (Marcus Stollsteimer) over 11 years ago

=begin
I think that would decrease readability of the code quite a lot (even more so for the first suggestion) and I don't see ((any)) benefit. It's only four characters.
=end

Updated by alexeymuranov (Alexey Muranov) over 11 years ago

@stomar (Marcus Stollsteimer), maybe you are right that self.foo = is more readable than @.foo = or .foo =, especially for someone who would see it for the first time. However, then it seems to me that bar = self.foo() is also more readable than just bar = foo. Maybe i do not understand what exactly is meant by "readability" here.

I agree that 4 characters is not a lot to be replaced with 1, but if all 4 were removed, as in the original proposal, i would have liked it.

The benefits i had in mind were a simpler way to disambiguate between a variable assignment and a method call, and greater similarity between setter and getter method calls.

Updated by stomar (Marcus Stollsteimer) over 11 years ago

=begin
A single dot is very unobtrusive. So I just think that .foo and foo resp. @.foo and @foo would look too similar to be easily distinguished, especially when browsing through larger pieces of code.
=end
=end

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0