This is probably going to be a terrible idea, but if Basket.line_items isn't safe, then maybe what's needed is a method on the model that returns a list of line_items that is safe.

|class Basket #or maybe Class ActiveRecord if you want it everywhere.
  def safe_line_items
    line_items || []
  end
end

#and

||<% @basket.safe_line_items.each do |item| %>
  <p><%= item %></p>
<% end %>|

1) Excuse any syntax errors as I've been away from Ruby for a while.
2) If this is a terrible idea, please tell me why this is a terrible idea.




Peter Morris wrote:
This discussion started when the need for a 'guard if' was removed because we ensured that the object we return behaves the same in all experienced cases. Injecting new differences to the interface would seem to be moving away from that ideal.

On 23 February 2016 at 19:45, Peter Morris <[email protected] <mailto:[email protected]>> wrote:

    When I say 'breaks ducks' I mean it breaks the implicit interface
    contract.

    I expect it to quack when I expect, not bark.

    On 23 February 2016 at 15:49, Graham Ashton <[email protected]
    <mailto:[email protected]>> wrote:

        On Tue, 23 Feb 2016, at 03:31 PM, Peter Morris wrote:

        > but having #save raise an exception breaks ducks. save
        doesn't raise exceptions.

        If it would be an error to call `#save` on a missing basket,
        your code won’t do it, so there’s no problem. If you make a
        mistake and your code does do it, you want to know about it,
        so you really want it to raise.

        Can you elaborate on what “breaks ducks” means? I’m finding it
        hard to describe what I think you’re trying to say. As in,
        what’s the actual problem?

        Are you saying that any object that quacks like a Duck must
        have the same API as Duck, even if you never call some of
        those methods on the duck-like object?

        Here’s another way to think about it…

        If I wrote `Basket` and `MissingBasket` from scratch (without
        inheritance, or ActiveRecord), and needed to call `#save` on
        both of them, I’d implement it on both of them (reusing code
        as/if appropriate).

        If I only ever needed to call it on `Basket` I wouldn’t define
        it on `MissingBasket` as well, just because `Basket` needed a
        `#save` method.

        --
        You received this message because you are subscribed to the
        Google Groups "North West Ruby User Group (NWRUG)" group.
        To unsubscribe from this group and stop receiving emails from
        it, send an email to
        [email protected]
        <mailto:nwrug-members%[email protected]>.
        To post to this group, send an email to
        [email protected]
        <mailto:[email protected]>.
        Visit this group at https://groups.google.com/group/nwrug-members.
        For more options, visit https://groups.google.com/d/optout.



--
You received this message because you are subscribed to the Google Groups "North West Ruby User Group (NWRUG)" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected] <mailto:[email protected]>. To post to this group, send email to [email protected] <mailto:[email protected]>.
Visit this group at https://groups.google.com/group/nwrug-members.
For more options, visit https://groups.google.com/d/optout.

--
Sean Bamforth
p: +44 (0)7802 653722
w: http://threeparams.com
e: [email protected]

--
You received this message because you are subscribed to the Google Groups "North 
West Ruby User Group (NWRUG)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send an email to [email protected].
Visit this group at https://groups.google.com/group/nwrug-members.
For more options, visit https://groups.google.com/d/optout.

Reply via email to