I was thinking on this issue as well and I've came up with the following:

def set_param(hash, param)
  key = param[:name]
  return hash if in_path?(key)
  keys = [param[:scope], key].flatten.compact
  method_name = keys.join('_')
  unless respond_to?(method_name)
    method_name = key
    return hash unless respond_to?(method_name)
  end
  hash.deep_merge(build_param_hash(keys, method_name))
end
def build_param_hash(keys, method_name)
  value = keys[1] ? build_param_hash(keys[1..-1], method_name) : send(method_name)
  { keys[0].to_s => value }
end

What do you think? This way we can keep the current way to set values without breaking any existing app:

parameter :quantity, 'Number', scope: :order
let(:quantity) { 42 }

Or the scoped version when there are different parameters with the same name:

parameter :quantity, 'Number', scope: [:data, :attributes] # OR [:data, [:attributes]] OR {data: :attributes}
let(:data_attributes_quantity) { 42 }

I've used the flatten method in order to have deep arrays and the single hash level working ( { data: { attributes: :something } } doesn't work). Otherwise it could be removed and specify in the docs that it only works with arrays and not hashes

All existing tests (rspec / cucumber) are green

Looks like there is some issues now with the documentation output for the parameters with nested scope.

Specifically parameter description and required label.

Are you referring to the travis break?

Checking on the travis history it seems that the same failed tests are present also in the last master commit, which only edits the README, and the previous commit fails with a different error, this doesn't make a lot of sense 😕

No, this is a different issue. The failing tests on master are unrelated. @oestrich

What issues are you having?

I've tried to generate the doc with some scopes on a project I'm working on and I see from the generated json files that the only difference is that the scope is an array (as expected), and that apitome doesn't show it correctly (eg: ["data", "attributes"][body] , instead of data[attributes][body]), but that'd need to be patched on apitome (I guess on raddocs as well, I haven't tried it).

Both the description and the required label are shown correctly though..

Yeah, the html could be cleaned up a little, and apitome and raddocs would need to be updated as well, but this is a good start.

This looks good, I think it should cover everything. I'll update the documentation after merging this along with updating Raddocs. I don't think it breaks anything either so I can release 4.5.0 soon.

It passes locally for me, not sure what's up with travis so I'm good on that end.