[LRUG] Rails - The Missing Parts

[Stephen Best]

@Tom Great post BTW, obviously you need some more dependency injection, but
we've probably argued about that enough :)

Also I'm glad people still have the energy to argue with DHH.


On 4 March 2014 10:29, Mike Kelly <mikekelly321 at gmail.com> wrote:

> Agreed. I don't use extend for decoration myself, just playing devils
> advocate.
>
> Cheers,
> M
> On 4 Mar 2014 10:24, "Stephen Best" <bestie at gmail.com> wrote:
>
>>
>> @Mike Good one! I can totally imagine someone giving that excuse. The
>> problem is it's missing the point of DCI.
>>
>> In that case your method privacy is at the wrong level, just have your
>> decorator not expose that method. If you have to rely on always having the
>> decorator that's fine, object composition is a thing that should be done.
>>
>> * I know that an object must delegate all methods to be a true decorator,
>> no trolls plz.
>>
>> On 4 Mar 2014, at 09:58, Mike Kelly <mikekelly321 at gmail.com> wrote:
>>
>> I can only come up with one: you can't call private methods via
>> delegation without resorting to `send`.
>> On 4 Mar 2014 09:37, "Stephen Best" <bestie at gmail.com> wrote:
>>
>>> Also why do Ruby developers insist on implementing DCI by mixing in
>>> modules at runtime? It's just completely unnecessary, why not decorate?
>>>
>>>
>>> Stephen Best
>>>
>>> +44 7745 790523
>>> theaudaciouscodeexpiment.com
>>> github.com/bestie
>>> @thebestie
>>>
>>>
>>> On 4 March 2014 09:35, Stephen Best <bestie at gmail.com> wrote:
>>>
>>>> DHH as usual saying the best way to design your objects is don't. GOOD
>>>> LUCK WITH THAT.
>>>>
>>>>
>>>> Stephen Best
>>>>
>>>> +44 7745 790523
>>>> theaudaciouscodeexpiment.com
>>>> github.com/bestie
>>>> @thebestie
>>>>
>>>>
>>>> On 3 March 2014 23:09, Mark Burns <markthedeveloper at gmail.com> wrote:
>>>>
>>>>> It's kind of similar, but DCI is kind of like a run-time only
>>>>> ActiveSupport::Concern.
>>>>> It's still a big bag o' methods, but a big dynamic bag of methods.
>>>>> Maybe less chance of collisions, but
>>>>> the principle is still the same as AS::Concern.
>>>>> Interactors in the sense of the interactor gem are cleaner as you're
>>>>> not polluting a potentially already
>>>>> overloaded domain model/persistence object hybrid.
>>>>>
>>>>>
>>>>> On 3 March 2014 22:18, Riccardo Tacconi <rtacconi at gmail.com> wrote:
>>>>>
>>>>>> Hi Tom,
>>>>>>
>>>>>> Your interactor reminds me the I part (interaction) of DCI, am I
>>>>>> wrong? I see few similarities.
>>>>>>
>>>>>>
>>>>>> On 3 March 2014 20:38, Tom Blomfield <tomblomfield at gmail.com> wrote:
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I wrote a blog post on Interactors in Rails -
>>>>>>> http://eng.joingrouper.com/blog/2014/03/03/rails-the-missing-parts-interactors
>>>>>>>
>>>>>>> You might enjoy the discussion on HN, with DHH wading in
>>>>>>> https://news.ycombinator.com/item?id=7335211
>>>>>>>
>>>>>>> Tom
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Chat mailing list
>>>>>>> Chat at lists.lrug.org
>>>>>>> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Riccardo Tacconi
>>>>>> Ruby on Rails and PHP development - System Administration
>>>>>> VIRTUELOGIC LIMITED <http://www.virtuelogic.net/>
>>>>>>
>>>>>> http://github.com/rtacconi
>>>>>> http://riccardotacconi.blogspot.com
>>>>>> http://twitter.com/rtacconi
>>>>>>
>>>>>> _______________________________________________
>>>>>> Chat mailing list
>>>>>> Chat at lists.lrug.org
>>>>>> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Chat mailing list
>>>>> Chat at lists.lrug.org
>>>>> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>>>>>
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> Chat mailing list
>>> Chat at lists.lrug.org
>>> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20140304/25a57c79/attachment-0003.html>