Hey, For a while now, I am thinking about implementing a feature into Rails. Since it''s not a simple single liner, I thought I should get feedback on it and maybe some guidelines before I continue on with coding it. The feature I would like to implement is nil_object pattern. Here''s some code for example https://gist.github.com/3655723 As you can see, the post belongs to a user and I am printing out the user display name for every post. This is a pretty common thing in every rails app I ever saw, some preload, some let it go N+1 without caring. The problem is, that if you don''t have the user in the database, the view code will fail on NoMethodError for NilClass. To Avoid this here''s what I want to do: https://gist.github.com/3655751 This way, if the database has no record for that user, it will load the nil_user class and the code will now break. This can come in handy not only for the belongs_to but for the has_one relation as well. So... This is the feature I want to implement, thoughts? feedback? guidelines? -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-core/-/BXbYp3KnUY0J. 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.
Joe Ferris
2012-Sep-07 17:28 UTC
Re: Feature feedback before working and pull request please..
This looks useful to me. If you did implement this, it would be less rigid if you accepted a class instead of a class name, because that would allow you to pass anything that responds to #new. -Joe On Thursday, September 6, 2012 8:29:40 AM UTC-4, Kensodev wrote:> > Hey, > > For a while now, I am thinking about implementing a feature into Rails. > Since it''s not a simple single liner, I thought I should get feedback on > it and maybe some guidelines before I continue on with coding it. > > The feature I would like to implement is nil_object pattern. > > Here''s some code for example > > https://gist.github.com/3655723 > > As you can see, the post belongs to a user and I am printing out the user > display name for every post. > > This is a pretty common thing in every rails app I ever saw, some preload, > some let it go N+1 without caring. > > The problem is, that if you don''t have the user in the database, the view > code will fail on NoMethodError for NilClass. > > To Avoid this here''s what I want to do: > > https://gist.github.com/3655751 > > This way, if the database has no record for that user, it will load the > nil_user class and the code will now break. > > This can come in handy not only for the belongs_to but for the has_one > relation as well. > > So... This is the feature I want to implement, thoughts? feedback? > guidelines? >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-core/-/EX61uUxjIkQJ. 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.
Carlos Antonio da Silva
2012-Sep-07 17:57 UTC
Re: Re: Feature feedback before working and pull request please..
I believe you should be able to achieve the same just by overriding the #user method in your class. I''ve commented on your last gist example with an example code to make things more clear. On Fri, Sep 7, 2012 at 2:28 PM, Joe Ferris <jferris@thoughtbot.com> wrote:> This looks useful to me. If you did implement this, it would be less rigid > if you accepted a class instead of a class name, because that would allow > you to pass anything that responds to #new. > > -Joe > > > On Thursday, September 6, 2012 8:29:40 AM UTC-4, Kensodev wrote: >> >> Hey, >> >> For a while now, I am thinking about implementing a feature into Rails. >> Since it''s not a simple single liner, I thought I should get feedback on >> it and maybe some guidelines before I continue on with coding it. >> >> The feature I would like to implement is nil_object pattern. >> >> Here''s some code for example >> >> https://gist.github.com/**3655723 <https://gist.github.com/3655723> >> >> As you can see, the post belongs to a user and I am printing out the user >> display name for every post. >> >> This is a pretty common thing in every rails app I ever saw, some >> preload, some let it go N+1 without caring. >> >> The problem is, that if you don''t have the user in the database, the view >> code will fail on NoMethodError for NilClass. >> >> To Avoid this here''s what I want to do: >> >> https://gist.github.com/**3655751 <https://gist.github.com/3655751> >> >> This way, if the database has no record for that user, it will load the >> nil_user class and the code will now break. >> >> This can come in handy not only for the belongs_to but for the has_one >> relation as well. >> >> So... This is the feature I want to implement, thoughts? feedback? >> guidelines? >> > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/rubyonrails-core/-/EX61uUxjIkQJ. > > 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. >-- At. Carlos Antonio -- 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.
Aaron Patterson
2012-Sep-07 18:42 UTC
Re: Re: Feature feedback before working and pull request please..
On Fri, Sep 07, 2012 at 02:57:25PM -0300, Carlos Antonio da Silva wrote:> I believe you should be able to achieve the same just by overriding the > #user method in your class. I''ve commented on your last gist example with > an example code to make things more clear.Agreed. We don''t need any framework support for the null object pattern. Just use Ruby. -- Aaron Patterson http://tenderlovemaking.com/
Kensodev
2012-Sep-08 18:57 UTC
Re: Re: Feature feedback before working and pull request please..
This kind of response is precisely why I came here first and didn''t just invest the time and opened a pull request. IMHO this should be supported in the frame work, and I will be more then happy to work on it if you guys think it should go in. I know Ruby can be used to override the relation. I actually had a plan that the loading of the "Nil class" will be automatically based on the relation name, but you can override it with the :nil_class definition. Anyway, let me know if you think it''s viable. On Friday, September 7, 2012 9:42:29 PM UTC+3, Aaron Patterson wrote:> > On Fri, Sep 07, 2012 at 02:57:25PM -0300, Carlos Antonio da Silva wrote: > > I believe you should be able to achieve the same just by overriding the > > #user method in your class. I''ve commented on your last gist example > with > > an example code to make things more clear. > > Agreed. We don''t need any framework support for the null object > pattern. Just use Ruby. > > -- > Aaron Patterson > http://tenderlovemaking.com/ >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-core/-/P9-vM1sUesMJ. 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.
Pascal Hurni
2012-Sep-08 19:18 UTC
Re: Re: Feature feedback before working and pull request please..
I understand the need behind your proposition but you want to insert
some behaviour for the view in the model.
This breaks the MVC separation.
I do a lot of the following:
if some_model.user
...
end
to check the presence of the association. Your proposition will break
this idiom which is IMHO heavily used in code.
Regards,
Pascal
Le 08.09.12 20:57, Kensodev a écrit :> This kind of response is precisely why I came here first and
didn''t
> just invest the time and opened a pull request.
> IMHO this should be supported in the frame work, and I will be more
> then happy to work on it if you guys think it should go in.
>
> I know Ruby can be used to override the relation.
>
> I actually had a plan that the loading of the "Nil class" will be
> automatically based on the relation name, but you can override it with
> the :nil_class definition.
>
> Anyway, let me know if you think it''s viable.
>
>
>
> On Friday, September 7, 2012 9:42:29 PM UTC+3, Aaron Patterson wrote:
>
> On Fri, Sep 07, 2012 at 02:57:25PM -0300, Carlos Antonio da Silva
> wrote:
> > I believe you should be able to achieve the same just by
> overriding the
> > #user method in your class. I''ve commented on your last
gist
> example with
> > an example code to make things more clear.
>
> Agreed. We don''t need any framework support for the null
object
> pattern. Just use Ruby.
>
> --
> Aaron Patterson
> http://tenderlovemaking.com/
>
> --
> You received this message because you are subscribed to the Google
> Groups "Ruby on Rails: Core" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/rubyonrails-core/-/P9-vM1sUesMJ.
> 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.
Kensodev
2012-Sep-09 10:07 UTC
Re: Re: Feature feedback before working and pull request please..
@Pascal. This is a complete Opt-In proposition, if you will not have the nil class present, it will not try to load it. The code in your sample is EXACTLY the kind of code that I want to avoid with this feature, you should "Tell" object and not "ask" objects. It will not break any existing code as long as you don''t opt into the nil class. On Saturday, September 8, 2012 10:18:17 PM UTC+3, Pascal Hurni wrote:> > I understand the need behind your proposition but you want to insert > some behaviour for the view in the model. > This breaks the MVC separation. > I do a lot of the following: > if some_model.user > ... > end > to check the presence of the association. Your proposition will break this > idiom which is IMHO heavily used in code. > > Regards, > > Pascal > > > Le 08.09.12 20:57, Kensodev a écrit : > > This kind of response is precisely why I came here first and didn''t just > invest the time and opened a pull request. > IMHO this should be supported in the frame work, and I will be more then > happy to work on it if you guys think it should go in. > > I know Ruby can be used to override the relation. > > I actually had a plan that the loading of the "Nil class" will be > automatically based on the relation name, but you can override it with the > :nil_class definition. > > Anyway, let me know if you think it''s viable. > > > > On Friday, September 7, 2012 9:42:29 PM UTC+3, Aaron Patterson wrote: >> >> On Fri, Sep 07, 2012 at 02:57:25PM -0300, Carlos Antonio da Silva wrote: >> > I believe you should be able to achieve the same just by overriding the >> > #user method in your class. I''ve commented on your last gist example >> with >> > an example code to make things more clear. >> >> Agreed. We don''t need any framework support for the null object >> pattern. Just use Ruby. >> >> -- >> Aaron Patterson >> http://tenderlovemaking.com/ >> > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/rubyonrails-core/-/P9-vM1sUesMJ. > To post to this group, send email to rubyonra...@googlegroups.com<javascript:> > . > To unsubscribe from this group, send email to > rubyonrails-co...@googlegroups.com <javascript:>. > 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 view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-core/-/4z6FB0nouM0J. 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.
Dennis Krupenik
2012-Sep-09 17:24 UTC
Re: Feature feedback before working and pull request please..
> > https://gist.github.com/3655723 > > As you can see, the post belongs to a user and I am printing out the user > display name for every post. > > This is a pretty common thing in every rails app I ever saw, some preload, > some let it go N+1 without caring. > > The problem is, that if you don''t have the user in the database, the view > code will fail on NoMethodError for NilClass. >that is exactly why we have #try: <%= post.try(:user) { |u| u.display_name } || "Unknown user" %> -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-core/-/s1xWDRN1jMAJ. 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.
Thibaut Barrère
2012-Sep-09 17:44 UTC
Re: Re: Feature feedback before working and pull request please..
Wouldn''t it be preferable to avoid basing the default behavior on the mere existence of a class? It could easily bite back, in case a ruby gem you use (or one of its dependencies) defines such a class. (Note that I''m personally very happy to get exceptions when the subject is nil, or to use try or similar helpers when I do not want that) -- Thibaut -- 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.
Pascal Hurni
2012-Sep-10 08:48 UTC
Re: Re: Feature feedback before working and pull request please..
Of course it''s an Opt-in, but once you decide that this association should use the NilUserClass, all of the application will be affected. The code i showed is not done in the View but in other models, in controllers or anywhere else. For example I have a serializer that takes the Post record, it will ask for the association, will get an object and try to serialize it which is NOT what I want because the association should have lead to nil. Once again, the problem here is that (even with opt-in) it affects the whole application (plugins, engines, etc...) and you still want to fix a view problem. Regards, Le 09.09.12 12:07, Kensodev a écrit :> @Pascal. > > This is a complete Opt-In proposition, if you will not have the nil > class present, it will not try to load it. > The code in your sample is EXACTLY the kind of code that I want to > avoid with this feature, you should "Tell" object and not "ask" objects. > > It will not break any existing code as long as you don''t opt into the > nil class. > > > > On Saturday, September 8, 2012 10:18:17 PM UTC+3, Pascal Hurni wrote: > > I understand the need behind your proposition but you want to > insert some behaviour for the view in the model. > This breaks the MVC separation. > I do a lot of the following: > if some_model.user > ... > end > to check the presence of the association. Your proposition will > break this idiom which is IMHO heavily used in code. > > Regards, > > Pascal > > > Le 08.09.12 20:57, Kensodev a écrit : >> This kind of response is precisely why I came here first and >> didn''t just invest the time and opened a pull request. >> IMHO this should be supported in the frame work, and I will be >> more then happy to work on it if you guys think it should go in. >> >> I know Ruby can be used to override the relation. >> >> I actually had a plan that the loading of the "Nil class" will be >> automatically based on the relation name, but you can override it >> with the :nil_class definition. >> >> Anyway, let me know if you think it''s viable. >> >> >> >> On Friday, September 7, 2012 9:42:29 PM UTC+3, Aaron Patterson >> wrote: >> >> On Fri, Sep 07, 2012 at 02:57:25PM -0300, Carlos Antonio da >> Silva wrote: >> > I believe you should be able to achieve the same just by >> overriding the >> > #user method in your class. I''ve commented on your last >> gist example with >> > an example code to make things more clear. >> >> Agreed. We don''t need any framework support for the null object >> pattern. Just use Ruby. >> >> -- >> Aaron Patterson >> http://tenderlovemaking.com/ >> >> -- >> You received this message because you are subscribed to the >> Google Groups "Ruby on Rails: Core" group. >> To view this discussion on the web visit >> https://groups.google.com/d/msg/rubyonrails-core/-/P9-vM1sUesMJ >> <https://groups.google.com/d/msg/rubyonrails-core/-/P9-vM1sUesMJ>. >> To post to this group, send email to rubyonra...@googlegroups.com >> <javascript:>. >> To unsubscribe from this group, send email to >> rubyonrails-co...@googlegroups.com <javascript:>. >> For more options, visit this group at >> http://groups.google.com/group/rubyonrails-core?hl=en >> <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 view this discussion on the web visit > https://groups.google.com/d/msg/rubyonrails-core/-/4z6FB0nouM0J. > 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.
Gabriel Sobrinho
2012-Sep-10 12:14 UTC
Re: Re: Feature feedback before working and pull request please..
I think this problem can be fixed in so many ways... Overwrite the association method, using try on view or create a new method like that: https://gist.github.com/3655751#gistcomment-567880 You can even use a decorator :) One important point is if you need that everywhere in your system, you have an architecture problem in your application. This is a sign, not a rule ;) On Monday, September 10, 2012 5:48:28 AM UTC-3, Pascal Hurni wrote:> > Of course it''s an Opt-in, but once you decide that this association > should use the NilUserClass, all of the application will be affected. > > The code i showed is not done in the View but in other models, in > controllers or anywhere else. For example I have a serializer that takes > the Post record, it will ask for the association, will get an object and > try to serialize it which is NOT what I want because the association should > have lead to nil. > > Once again, the problem here is that (even with opt-in) it affects the > whole application (plugins, engines, etc...) and you still want to fix a > view problem. > > Regards, > > Le 09.09.12 12:07, Kensodev a écrit : > > @Pascal. > > This is a complete Opt-In proposition, if you will not have the nil > class present, it will not try to load it. > The code in your sample is EXACTLY the kind of code that I want to avoid > with this feature, you should "Tell" object and not "ask" objects. > > It will not break any existing code as long as you don''t opt into the > nil class. > > > > On Saturday, September 8, 2012 10:18:17 PM UTC+3, Pascal Hurni wrote: >> >> I understand the need behind your proposition but you want to insert >> some behaviour for the view in the model. >> This breaks the MVC separation. >> I do a lot of the following: >> if some_model.user >> ... >> end >> to check the presence of the association. Your proposition will break >> this idiom which is IMHO heavily used in code. >> >> Regards, >> >> Pascal >> >> >> Le 08.09.12 20:57, Kensodev a écrit : >> >> This kind of response is precisely why I came here first and didn''t just >> invest the time and opened a pull request. >> IMHO this should be supported in the frame work, and I will be more then >> happy to work on it if you guys think it should go in. >> >> I know Ruby can be used to override the relation. >> >> I actually had a plan that the loading of the "Nil class" will be >> automatically based on the relation name, but you can override it with the >> :nil_class definition. >> >> Anyway, let me know if you think it''s viable. >> >> >> >> On Friday, September 7, 2012 9:42:29 PM UTC+3, Aaron Patterson wrote: >>> >>> On Fri, Sep 07, 2012 at 02:57:25PM -0300, Carlos Antonio da Silva wrote: >>> > I believe you should be able to achieve the same just by overriding >>> the >>> > #user method in your class. I''ve commented on your last gist example >>> with >>> > an example code to make things more clear. >>> >>> Agreed. We don''t need any framework support for the null object >>> pattern. Just use Ruby. >>> >>> -- >>> Aaron Patterson >>> http://tenderlovemaking.com/ >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "Ruby on Rails: Core" group. >> To view this discussion on the web visit >> https://groups.google.com/d/msg/rubyonrails-core/-/P9-vM1sUesMJ. >> To post to this group, send email to rubyonra...@googlegroups.com. >> To unsubscribe from this group, send email to >> rubyonrails-co...@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 view this discussion on the web visit > https://groups.google.com/d/msg/rubyonrails-core/-/4z6FB0nouM0J. > To post to this group, send email to rubyonra...@googlegroups.com<javascript:> > . > To unsubscribe from this group, send email to > rubyonrails-co...@googlegroups.com <javascript:>. > 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 view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-core/-/TI39lh-vBLsJ. 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.
Jay Feldblum
2012-Sep-10 22:02 UTC
Re: Feature feedback before working and pull request please..
Sometimes the null-object pattern is a good pattern: for example, in views, when you need to show default text when an object is missing. But the rest of the time, it is a bad pattern, or an anti-pattern. I think that pushing the null-object pattern into ActiveRecord is a mistake. It is not an active-record concern; it is not a domain-model concern; it is a view concern only, a "last-mile" concern if you will. This pattern sometimes appears to solve a problem of code which could be made more concise, if only ________. But when actually applied consistently and automatically throughout a codebase at the domain-model layer, it will create more problems than it solves, and the problems it creates will be worse than the problems that it solves. The following visceral analogy seems to me to apply: it is like solving the problem of a stubbed toe by hacking off your whole foot. You can of course use null-objects explicitly in your views, without pushing them into ActiveRecord. And there are many other solutions too. On Thursday, September 6, 2012 8:29:40 AM UTC-4, Kensodev wrote:> Hey, > > For a while now, I am thinking about implementing a feature into Rails. > Since it''s not a simple single liner, I thought I should get feedback on > it and maybe some guidelines before I continue on with coding it. > > The feature I would like to implement is nil_object pattern. > > Here''s some code for example > > https://gist.github.com/3655723 > > As you can see, the post belongs to a user and I am printing out the user > display name for every post. > > This is a pretty common thing in every rails app I ever saw, some preload, > some let it go N+1 without caring. > > The problem is, that if you don''t have the user in the database, the view > code will fail on NoMethodError for NilClass. > > To Avoid this here''s what I want to do: > > https://gist.github.com/3655751 > > This way, if the database has no record for that user, it will load the > nil_user class and the code will now break. > > This can come in handy not only for the belongs_to but for the has_one > relation as well. > > So... This is the feature I want to implement, thoughts? feedback? > guidelines? >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-core/-/s71dOwnmu2UJ. 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.
Donald Ball
2012-Sep-10 23:17 UTC
Re: Re: Feature feedback before working and pull request please..
I disagree strongly with the assertion that null object is a view concern only. Null objects are useful anytime you want to provide default behavior in the absence of a specific result. Views tend to have lots of these cases, but there are plenty of other places they can to be useful as well, including in your models and in your domain. I confess, I''m having trouble thinking of an example where I''d rather receive nil from sending a message to which I expect a response than a null object or false. For what it''s worth, if ActiveRecord introduced a null object option for belongs_to and has_one associations, I would always use it. -- donald -- 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.
Richard Schneeman
2012-Sep-11 14:57 UTC
Re: Re: Feature feedback before working and pull request please..
The OP was asking for feedback, I believe they''ve gotten it. If they want to discuss it further they can make a PR, and the discussion can be moved there. Thanks to all who participated, as a reminder there are 478 open issues and 172 active and open pull requests that could use similar attention: https://github.com/rails/rails/issues?state=open. -- Richard Schneeman http://heroku.com @schneems (http://twitter.com/schneems) -- 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.
Rafael Mendonça França
2012-Sep-11 15:01 UTC
Re: Re: Feature feedback before working and pull request please..
I guess we have some :-1: from the Core team here, so either in a pull request I think we will not accept, so please don''t open it. As you pointed we have a lot of open pull requests and we are trying to no leave feature proposal / requests there and we always ask to move the discussion to here. I have the same opinion of Aaron. We don''t need support for Null object in Rails since you can do with plain Ruby. And thank you to remember that there are a lot of open issues, Richard. You are helping a lot. Rafael Mendonça França http://twitter.com/rafaelfranca https://github.com/rafaelfranca On Tue, Sep 11, 2012 at 11:57 AM, Richard Schneeman < richard.schneeman@gmail.com> wrote:> The OP was asking for feedback, I believe they''ve gotten it. If they want > to discuss it further they can make a PR, and the discussion can be moved > there. Thanks to all who participated, as a reminder there are 478 open > issues and 172 active and open pull requests that could use similar > attention: https://github.com/rails/rails/issues?state=open. > > -- > Richard Schneeman > http://heroku.com > @schneems <http://twitter.com/schneems> > > > -- > 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.
Kensodev
2012-Sep-11 15:55 UTC
Re: Re: Feature feedback before working and pull request please..
Thank you all for the feedback. Like Rafael and Aaron said, they think it does not belong in rails. Although I disagree, I appreciate the feedback and definitely happy I took the time to ask for it here before opening a pull and taking more attention from the core team for something that was not going to get accepted anyway. On Tuesday, September 11, 2012 6:02:29 PM UTC+3, Rafael Mendonça França wrote:> > I guess we have some :-1: from the Core team here, so either in a pull > request I think we will not accept, so please don''t open it. As you pointed > we have a lot of open pull requests and we are trying to no leave feature > proposal / requests there and we always ask to move the discussion to here. > > I have the same opinion of Aaron. We don''t need support for Null object in > Rails since you can do with plain Ruby. > > And thank you to remember that there are a lot of open issues, Richard. > You are helping a lot. > > Rafael Mendonça França > http://twitter.com/rafaelfranca > https://github.com/rafaelfranca > > > > On Tue, Sep 11, 2012 at 11:57 AM, Richard Schneeman <richard....@gmail.com<javascript:> > > wrote: > >> The OP was asking for feedback, I believe they''ve gotten it. If they want >> to discuss it further they can make a PR, and the discussion can be moved >> there. Thanks to all who participated, as a reminder there are 478 open >> issues and 172 active and open pull requests that could use similar >> attention: https://github.com/rails/rails/issues?state=open. >> >> -- >> Richard Schneeman >> http://heroku.com >> @schneems <http://twitter.com/schneems> >> >> >> -- >> 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 rubyonra...@googlegroups.com<javascript:> >> . >> To unsubscribe from this group, send email to >> rubyonrails-co...@googlegroups.com <javascript:>. >> 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 view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-core/-/QMWwIzn4gZAJ. 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.