Re: [Rails-core] Re: Feature feedback before working and pull request please..

[Carlos Antonio da Silva]

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

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

--
At.
Carlos Antonio

[Aaron Patterson]

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]

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.

[Pascal Hurni]

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 :

--

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.

[Kensodev]

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

[Dennis Krupenik]

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" %>

[Thibaut Barrère]

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

[Pascal Hurni]

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 :

To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-core/-/4z6FB0nouM0J.

[Gabriel Sobrinho]

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 ;)

[Jay Feldblum]

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.

[Donald Ball]

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

[Richard Schneeman]

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

[Rafael Mendonça França]

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

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.

[Kensodev]

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.