Thanks, Gabriel. The one place it was a pain, I just did array wrapping and
unsplat to remedy, e.g. before I had:
def some_method(relation, param_name)
# ... other code
relation.joins!(opts[:joins])
# ...
opts.reverse_merge(attr_name: param_name.to_sym)
end
# in code that calls it...
opts = some_method(relation, param_name)
now I have:
def some_method(relation, param_name)
# ... other code
relation = relation.joins(opts[:joins])
# ...
[relation, opts.reverse_merge(attr_name: param_name.to_sym)]
end
# in code that calls it...
relation, opts = *some_method(relation, param_name)
It's doing more than I'd like (having to create another array to wrap the
result, and all of the additional operations in joins(...) vs.
joins!(...)), but that's ok.
Gary
On Tue, Nov 5, 2013 at 7:55 AM, Gabriel Sobrinho <[email protected]
> wrote:
> França,
>
> I'm too late to the party, I thought these bang methods was public on
> rails 4 :(
>
> We will have people doing wrong things with these methods but a good
> documentation will reduce that, ruby itself have a lot of these methods
> like params.merge!(..) or controller_name.gsub!(...) and I never saw people
> (that do not means there is no people reporting, I just don't saw)
> reporting issues because things like that.
>
> The problem of scopes that must not be mutated can be solved using some
> freeze implementation on that scope, like this:
>
> relation = User.where(:dumb => false).immutable!
> relation.where!(:dumb => true)
> #=> raises ActiveRecord::ImmutableRelation
>
> I agree that new developers may do strange things but the rails itself is
> not so easy for beginners, but I have no expertise about how it may impact
> the community, so if you guys think that won't be great these methods be
> public, :okaymeme:
>
>
> Gary,
>
> What I usually do when "mutable relations" makes sense are filters like
> that: https://gist.github.com/sobrinho/7318585
>
>
> On Monday, November 4, 2013 1:01:59 PM UTC-2, Rafael Mendonça França wrote:
>
>> Yes, there is https://github.com/rails/rails/commit/
>> 8c2c60511beaad05a218e73c4918ab89fb1804f0#commitcomment-2211685
>>
>> Rafael Mendonça França
>> http://twitter.com/rafaelfranca
>> https://github.com/rafaelfranca
>>
>>
>> On Mon, Nov 4, 2013 at 11:53 AM, Gabriel Sobrinho
>> <[email protected]>wrote:
>>
>>> França,
>>>
>>> There is a reason for that? They sound useful in a lot of scenarios.
>>>
>>> On Wednesday, October 30, 2013 2:02:54 PM UTC-2, Rafael Mendonça França
>>> wrote:
>>>
>>>> The bang methods are private and should not be used in applications
>>>> (see the :nodoc: in the method definition)
>>>>
>>>> Rafael Mendonça França
>>>> http://twitter.com/rafaelfranca
>>>> https://github.com/rafaelfranca
>>>>
>>>>
>>>> On Wed, Oct 30, 2013 at 1:51 PM, Gary Weaver <[email protected]>wrote:
>>>>
>>>>> I understand that bang methods in the classic Ruby sense are
>>>>> supposed to alter the current instance, but getting errors like:
>>>>>
>>>>> NoMethodError: undefined method `where!' for #<Class:0x007ff1522d3110>
>>>>>
>>>>> and
>>>>>
>>>>> NoMethodError: undefined method `includes!' for
>>>>> #<Class:0x007ff1522d3110>
>>>>>
>>>>> when calling the bang methods from QueryMethods on a model class are
>>>>> really not helpful.
>>>>>
>>>>> It's understandable that you don't want to pass a model class into a
>>>>> method that expects a relation that it can act upon and change with a bang
>>>>> query method and have it successfully create a new relation and call some
>>>>> method on it that is never again seen, hence the error. I also understand
>>>>> wanting to avoid any more checking/raising code than necessary in
>>>>> ActiveRecord both for maintainability, clarity, and maybe efficiency- but
>>>>> just look at this:
>>>>>
>>>>> 2.0.0p247 :001 > MyModel.to_s
>>>>> => "MyModel"
>>>>> 2.0.0p247 :002 > MyModel.new.to_s
>>>>> => "#< MyModel:0x007fc92aa017e8>"
>>>>> 2.0.0p247 :003 > MyModel.where({})
>>>>> => ...
>>>>> 2.0.0p247 :003 > MyModel.where!({})
>>>>> NoMethodError: undefined method `where!' for #<Class:0x007fc92a95a240>
>>>>>
>>>>> Thanks!
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "Ruby on Rails: Core" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to [email protected].
>>>>> To post to this group, send email to [email protected].
>>>>>
>>>>> Visit this group at http://groups.google.com/group/rubyonrails-core.
>>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>>
>>>>
>>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Ruby on Rails: Core" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected].
>>> To post to this group, send email to [email protected].
>>> Visit this group at http://groups.google.com/group/rubyonrails-core.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>
>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Ruby on Rails: Core" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/rubyonrails-core/4YusNsRI4Kk/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> [email protected].
> To post to this group, send email to [email protected].
> Visit this group at http://groups.google.com/group/rubyonrails-core.
> For more options, visit https://groups.google.com/groups/opt_out.
>
--
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/groups/opt_out.
