[Catalyst] plugins; was Re: debug mode

[Maurice Aubrey]

Matt S Trout wrote:
> On Thu, Jun 07, 2007 at 03:12:10PM -0700, mla wrote:
>> Matt S Trout wrote:
>>> On Thu, Jun 07, 2007 at 01:04:02PM -0700, mla wrote:
>>>> Other than the fact you don't like the style, why is it bad?
>>>> You don't like singletons?
>>> I'm not fond of any magic global if I can possibly avoid it - I find it
>>> tends to encourage tight coupling of code and action at a distance and
>>> makes testing and debugging messy.
>> But if you are going to use ACCEPT_CONTEXT then you are tightly
>> coupling the model to the application.
>>
>> I agree that should be avoided... but they are equivalent if not
>> more tightly coupled by adding the context to the actual model instance.
> 
> I -don't- tend to hang onto the entire $c in ACCEPT_CONTEXT, I might set
> something like a current user (or in the case of the Paypal-IPN model I
> wrote it hangs onto $c->req to pass as a CGI-object-equivalent when it
> builds the IPN object).
> 
> The point is the singleton approach only makes the "I want the whole context"
> case easier, which is very rarely the case that comes up with a correct
> design.

Yes, I like that point.

>> In terms of testing, seems like the singleton is a bit better since you
>> have no ACCEPT_CONTEXT method to test.
> 
> Separating out the interrogation of the context and retrieval of data into
> the ACCEPT_CONTEXT is how you avoid loose coupling - and it also then means
> you know you have -one- method that requires a mocked $c to test rather
> than potentially any in your entire codebase needing that.

Avoid loose coupling? You mean tight?

I was thinking you're basically pushing the mocked $c testing to the
singleton class. If it works, then any code that uses it should work.
The retrieval of the data is already handled for you (by the singleton).
You just have to interrogate it, so one less piece.

>> I don't see how debugging would be any harder.
>>
>>> I prefer anything a method call needs to have been either (a) passed to the
>>> object when it was constructed or (b) passed to the method as it's called.
>>>
>>> It can be a bit more work up-front but it makes you think about your
>>> architecture, which I find pays off down the road.
>> A method call could also need to have access to other modules/packages
>> it will delegate to. The singleton seems equivalent.
> 
> I don't do that either. I generally create associated objects via factory
> methods and have an attribute for the related class with a default.
> 
> An example of this would be the _action_class member of Catalyst::Controller,
> which is what defaults you to Catalyst::Action as your action class - related
> classes should -always- be overridable.

There are lots of cases where you wouldn't do that though.

Like if you need to make some directories, you're not going to have a
new_file_path_like_object() methods and a default_file_path_class().
You're just going to use File::Path.

But your point being that you want your models to work with any
Catalyst-type-thingy, rather than assuming it's part of your Catalyst
application? Hmmm.

So what do you think of things like Perl's @INC? How would you implement
it without the equivalent of a singleton class?

And if a class wanted to access it, would you write something equivalent
to an ACCEPT_CONTEXT method that would be passed the Perl environment?