ruby-core

Issue #18603 has been updated by hmdne (hmdne -).


@sawa - My proposal would be to allow omitting parentheses only if there are no arguments provided, ie. how it is currently.

```ruby
self.xyz = 6 # correct currently
self.xyz() = 6 # correct under the proposal
self.xyz(a) = 6 # correct under the proposal
self.xyz a = 6 # parser conflict, it is already a correct code meaning something else
```

I am not very familiar with MRI code unfortunately, so I can't estimate if this will introduce a lot of complexity or not. Certainly lvalue will need to accept a lot more types of expression. I develop an alternative Ruby implementation (Opal), though not its parser, and there I have a clear path for implementation of this feature.

A similar, though a little different, feature exists in C, where `*get_mem(123) = 123` is a correct code.

Another argument for this feature is that it's easy to pass an arbitrary number of arguments to any operator, like `+`, `*`, `[]=`, `[]`, `something?`, `something!`. From what I know, `something=` is the only kind of operator that needs `__send__` to pass other number of arguments than 1 (`self.x=(1,2,3)` is not a correct code, perhaps it could be an alternative to accept it, instead of this proposal, but I assume it will be a lot harder).

I happen to sometimes want to add an optional argument to setter and it ends up with a code refactor that makes code a lot more complicated, needing methods like `set_x`, while I can easily add arguments to a getter.

@baweaver

>The difficulty for such functions is how to differentiate between the varadic path and the value setter

While block adds a lot of flexibility for certain cases, like `bury`, this proposal more clearly separates what's a variadic path and what's a value (following the semantics of `[]` and `[]=` operators). Perhaps my pseudo-code with `dig=` isn't the greatest idea, but it demonstrates the concept.

A more real life example happened in my code. I wanted to create an API like the following:

```ruby
entity.attribute(3) # => value of attribute 3
entity.attribute("attrtype 3 by name") # => value of attribute 3
entity.attribute(AttrType.new(3)) # => value of attribute 3
entity.attribute(3) = 10
entity.attribute("attrtype 3 by name") = 10
entity.attribute(AttrType.new(3)) = 10
```

Of course I ended up with extending `Hash` to accurately resolve the hash keys. Instead of the API described above, I created this:

```ruby
entity.attributes[3] # => value of attribute 3
entity.attributes["attrtype 3 by name"] # => value of attribute 3
entity.attributes[AttrType.new(3)] # => value of attribute 3
entity.attributes[3] = 10
entity.attributes["attrtype 3 by name"] = 10
entity.attributes[AttrType.new(3)] = 10
```

While I achieved the same goal by it, the resulting API implementation added a lot of complexity.

----------------------------------------
Feature #18603: Allow syntax like obj.method(arg)=value
https://bugs.ruby-lang.org/issues/18603#change-96681

* Author: hmdne (hmdne -)
* Status: Open
* Priority: Normal
----------------------------------------
I propose here to allow a syntax like:

```ruby
obj.method(arg) = value
```

It would be translated to the following:

```ruby
obj.__send__(:method=, arg, value)
```

The lack of this syntax kind of limits the ability to design DSLs in Ruby in my opinion. I don't think this would bring any conflicts with existing parser rules.

My proposal would be to put the value at the last argument, akin to how `[]=` works. So, for example this code would work:

```ruby
module Indexable
  def dig=(*path, last, value)
    if path.empty?
      self[last] = value
    else
      first = path.shift
      self[first]&.dig(*path, last) = value
    end
  end
end

Hash.include Indexable
Array.include Indexable
```

The kwargs may be supported similarly to how they work on `[]=`, ie. becoming a penultimate Hash argument. While maybe not perfect, it is consistent with how `[]=` works and I imagine most usecases won't require kwargs.



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>

Thread

Prev Next

In This Thread

Prev Next