try method under ActiveModel

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

I mean:

'string'.try :inexistent_method

yields an error...

Thanks in advance,

Rodrigo.

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

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.

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?

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

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)

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.

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

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...

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...

Mateo Murphy escreveu: