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?
_______________________________________________
List: [email protected]
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
