Is there any reason why ''try'' method behaves differently in ActiveModel? I mean: ''string''.try :inexistent_method yields an error... Thanks in advance, Rodrigo. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Thu, Dec 31, 2009 at 6:45 AM, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com> wrote:> 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 -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Jeremy Kemper escreveu:> On Thu, Dec 31, 2009 at 6:45 AM, Rodrigo Rosenfeld Rosas > <rr.rosas@gmail.com> wrote: > >> 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'' > > jeremyHi 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. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On 31-Dec-09, at 2:05 PM, Rodrigo Rosenfeld Rosas wrote:>> > 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? -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Thu, Dec 31, 2009 at 11:05 AM, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com> wrote:> Jeremy Kemper escreveu: >> On Thu, Dec 31, 2009 at 6:45 AM, Rodrigo Rosenfeld Rosas >> <rr.rosas@gmail.com> wrote: >> >>> 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 -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Jeremy Kemper escreveu:> On Thu, Dec 31, 2009 at 11:05 AM, Rodrigo Rosenfeld Rosas > <rr.rosas@gmail.com> wrote: > >> Jeremy Kemper escreveu: >> >>> On Thu, Dec 31, 2009 at 6:45 AM, Rodrigo Rosenfeld Rosas >>> <rr.rosas@gmail.com> wrote: >>> >>> >>>> 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. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Mateo Murphy escreveu:> On 31-Dec-09, at 2:05 PM, Rodrigo Rosenfeld Rosas wrote: > >> 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. :) Thank you for your interest, Rodrigo. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
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
On Thu, Dec 31, 2009 at 4:11 PM, Rodrigo Rosenfeld Rosas
<rr.rosas@gmail.com> wrote:
> Mateo Murphy escreveu:
> > On 31-Dec-09, at 2:05 PM, Rodrigo Rosenfeld Rosas wrote:
> >
> >> 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. :)
>
> Thank you for your interest,
>
> Rodrigo.
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> To unsubscribe from this group, send email to
>
rubyonrails-core+unsubscribe@googlegroups.com<rubyonrails-core%2Bunsubscribe@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/rubyonrails-core?hl=en.
>
>
>
--
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
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...> > Allen Madsen > http://www.allenmadsen.com > > > On Thu, Dec 31, 2009 at 4:11 PM, Rodrigo Rosenfeld Rosas > <rr.rosas@gmail.com <mailto:rr.rosas@gmail.com>> wrote: > > Mateo Murphy escreveu: > > On 31-Dec-09, at 2:05 PM, Rodrigo Rosenfeld Rosas wrote: > > > >> 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. :) > > Thank you for your interest, > > Rodrigo. > > -- > > You received this message because you are subscribed to the Google > Groups "Ruby on Rails: Core" group. > To post to this group, send email to > rubyonrails-core@googlegroups.com > <mailto:rubyonrails-core@googlegroups.com>. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com > <mailto:rubyonrails-core%2Bunsubscribe@googlegroups.com>. > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en. > > > > -- > > You received this message because you are subscribed to the Google > Groups "Ruby on Rails: Core" group. > To post to this group, send email to rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en.-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On 31-Dec-09, at 4:44 PM, Rodrigo Rosenfeld Rosas wrote:>> > 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... -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Mateo Murphy escreveu:> On 31-Dec-09, at 4:44 PM, Rodrigo Rosenfeld Rosas wrote: > >> 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... >Yes, I''ve read the documentation too after my tryout didn''t work as I expected... What I didn''t find was an instruction about how to subclass a String.... Did someone already tried this out? Best regards, Rodrigo. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.