try method under ActiveModel

rubyonrails-core
1

Is there any reason why 'try' method behaves differently in ActiveModel?

I mean:

'string'.try :inexistent_method

yields an error...

Thanks in advance,

Rodrigo.

2

When you use Active Model standalone, you need to cherry-pick the Active Support core extensions you wish to use:   require 'active_support/core_ext/object/try'

Or, to use them all:   require 'active_support/all'

jeremy

3

Jeremy Kemper escreveu:

  

Is there any reason why 'try' method behaves differently in ActiveModel?

I mean:

'string'.try :inexistent_method

yields an error...

Thanks in advance,      When you use Active Model standalone, you need to cherry-pick the Active Support core extensions you wish to use:   require 'active_support/core_ext/object/try'

Or, to use them all:   require 'active_support/all'

jeremy

Hi Jeremy, thank you for your reply.

Actually I'll avoid using try since I am writing a patch to ActiveModel and it seems that ActiveModel should not depend on ActiveSupport, right?

I'm writing this pattern, instead: "foo = bar.inexistent_method if bar.responds_to? :inexistent_method"

I'm a bit confuse about how to add a :full_message option to validations without breaking backward compatibilities... Subclassing String doesn't seem to be easy.

I'm inclined to do something like 'string'.extend SomeHelperClass and :symbol.extend SomeHelperClass...

Have a good new year!

Best regards,

Rodrigo.

4

I'm not sure why you'd need to subclass string to add a full_message option to validations? Could you explain how you were planning on doing this?

5

Active Model does depend on Active Support, but it cherry-picks just what it needs rather than including the whole enchilada. So you're free to use the try extension.

jeremy

6

Jeremy Kemper escreveu:

  

Jeremy Kemper escreveu:     

Is there any reason why 'try' method behaves differently in ActiveModel?

I mean:

'string'.try :inexistent_method

yields an error...

Thanks in advance,

When you use Active Model standalone, you need to cherry-pick the Active Support core extensions you wish to use:   require 'active_support/core_ext/object/try'

Or, to use them all:   require 'active_support/all'

jeremy       

Hi Jeremy, thank you for your reply.

Actually I'll avoid using try since I am writing a patch to ActiveModel and it seems that ActiveModel should not depend on ActiveSupport, right?      Active Model does depend on Active Support, but it cherry-picks just what it needs rather than including the whole enchilada. So you're free to use the try extension.

jeremy   

Hi Jeremy and Mateo, thank you for your feedback.

Mateo, I did not answer you before because I wanted to finish my attempt and show it instead of talk about it.

Follows a patch in attachment (still missing tests and documentation) to illustrate my idea.

If you think that could be accepted, I will add the tests, documentation and will probably require the 'try' from active_support for better readability.

What do you think?

Anyway, I want to wish all rails-core list members a happy new year!

Best regards,

Rodrigo.

0001-Include-support-for-full_message-option-to-validatio.patch (10.6 KB)

7

Mateo Murphy escreveu:

  

Hi Jeremy, thank you for your reply.

Actually I'll avoid using try since I am writing a patch to ActiveModel and it seems that ActiveModel should not depend on ActiveSupport, right?

I'm writing this pattern, instead: "foo = bar.inexistent_method if bar.responds_to? :inexistent_method"

I'm a bit confuse about how to add a :full_message option to validations without breaking backward compatibilities... Subclassing String doesn't seem to be easy.

I'm inclined to do something like 'string'.extend SomeHelperClass and :symbol.extend SomeHelperClass...      I'm not sure why you'd need to subclass string to add a full_message option to validations? Could you explain how you were planning on doing this?   

Mateo, I was thinking in extending String because I didn't want to break backwards compatibility, like changing Errors#add* method signatures and I would like to preserve all the options on the attributes array.

I ended up giving up on this approach and only included a "full_message" state on the validation.

I also has learned a bit more about Ruby... What would you expect from the following snippet?

class NewString < String   def initialize(options={})   end   def to_s     options[:message]   end end

puts NewString.new(:message => 'Hi')

I expected it would be 'Hi', but it is actually nil. :slight_smile:

Thank you for your interest,

Rodrigo.

8

Rodrigo,

You should be doing something like:

class NewString < String def initialize(options={})

@options = options end def to_s @options[:message] end end

That will give you the desired result.

Allen Madsen http://www.allenmadsen.com

9

Allen Madsen escreveu:

Rodrigo,

You should be doing something like: class NewString < String def initialize(options={})   @options = options end def to_s    @options[:message] end end

That will give you the desired result.

Sorry, that was exactly what I did (I have not copied and pasted). Actually it was more like this:

class NewString < String attr_reader :options def initialize(options={})   @options = options end def to_s    options[:message] end end

Did you try your example?

It didn't work here...

10

print (which is called by puts) only calls to_s on objects that are not strings. You might get this to work by implementing a different method, but I'm not sure subclassing is the right way to go about this in the first place...

11

Mateo Murphy escreveu: