Re: [Catalyst] plugins; was Re: debug mode
mia wrote: Matt S Trout wrote: On Wed, Jun 06, 2007 at 02:18:33PM -0700, mla wrote: Matt S Trout wrote: On Wed, Jun 06, 2007 at 12:29:12PM -0700, mla wrote: Is it not possible to offer the current Catalyst instance through a class method? Something analogous to Apache-request, rather than having to do the whole ACCEPT_CONTEXT prototype object thing? Not without limiting ourselves in terms of planned future features. Jifty does this because they're explicitly one app per process. We aren't. When you say per process, you mean operating system process? You're talking about threading issues? Threading, forking, and OS-level COW. Forking and COW would apply just as much to instances though. Assuming I'm not using threads, how would I hurt myself by subclassing Catalyst and supplying a MyApp-context that returns the current catalyst context? Yes, I'd like to know more about this too please. Mason has a similar construct - HTML::Mason::Request-instance() - and it works fine with Mason subrequests or recursive calls to an entirely different Mason interpreter. It just returns the value of a dynamically scoped variable that is set at the beginning of a Mason request. I dislike the fact that anything that needs to access the current context object has to be written as a component, and thus have a completely different calling signature than just a plain extension. Jon ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] plugins; was Re: debug mode
On Thu, Jun 07, 2007 at 03:55:16AM -0700, Jonathan Swartz wrote: mia wrote: Matt S Trout wrote: On Wed, Jun 06, 2007 at 02:18:33PM -0700, mla wrote: Matt S Trout wrote: On Wed, Jun 06, 2007 at 12:29:12PM -0700, mla wrote: Is it not possible to offer the current Catalyst instance through a class method? Something analogous to Apache-request, rather than having to do the whole ACCEPT_CONTEXT prototype object thing? Not without limiting ourselves in terms of planned future features. Jifty does this because they're explicitly one app per process. We aren't. When you say per process, you mean operating system process? You're talking about threading issues? Threading, forking, and OS-level COW. Forking and COW would apply just as much to instances though. Assuming I'm not using threads, how would I hurt myself by subclassing Catalyst and supplying a MyApp-context that returns the current catalyst context? Yes, I'd like to know more about this too please. Mason has a similar construct - HTML::Mason::Request-instance() - and it works fine with Mason subrequests or recursive calls to an entirely different Mason interpreter. It just returns the value of a dynamically scoped variable that is set at the beginning of a Mason request. If you like that style, load Catalyst::Plugin::Singleton and enjoy. I don't but I'm not the arbiter of bad code :) I dislike the fact that anything that needs to access the current context object has to be written as a component, and thus have a completely different calling signature than just a plain extension. Different how? ACCEPT_CONTEXT tricks are generally transparent to the rest of the code in that class. -- Matt S Trout Need help with your Catalyst or DBIx::Class project? Technical DirectorWant a managed development or deployment platform? Shadowcat Systems Ltd. Contact mst (at) shadowcatsystems.co.uk for a quote http://chainsawblues.vox.com/ http://www.shadowcatsystems.co.uk/ ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] plugins; was Re: debug mode
Matt S Trout wrote: On Thu, Jun 07, 2007 at 03:55:16AM -0700, Jonathan Swartz wrote: mia wrote: Matt S Trout wrote: On Wed, Jun 06, 2007 at 02:18:33PM -0700, mla wrote: Assuming I'm not using threads, how would I hurt myself by subclassing Catalyst and supplying a MyApp-context that returns the current catalyst context? Yes, I'd like to know more about this too please. Mason has a similar construct - HTML::Mason::Request-instance() - and it works fine with Mason subrequests or recursive calls to an entirely different Mason interpreter. It just returns the value of a dynamically scoped variable that is set at the beginning of a Mason request. If you like that style, load Catalyst::Plugin::Singleton and enjoy. I don't but I'm not the arbiter of bad code :) Cool, that's exactly what I was hoping for. Other than the fact you don't like the style, why is it bad? You don't like singletons? ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] plugins; was Re: debug mode
On Thu, Jun 07, 2007 at 01:04:02PM -0700, mla wrote: Matt S Trout wrote: On Thu, Jun 07, 2007 at 03:55:16AM -0700, Jonathan Swartz wrote: mia wrote: Matt S Trout wrote: On Wed, Jun 06, 2007 at 02:18:33PM -0700, mla wrote: Assuming I'm not using threads, how would I hurt myself by subclassing Catalyst and supplying a MyApp-context that returns the current catalyst context? Yes, I'd like to know more about this too please. Mason has a similar construct - HTML::Mason::Request-instance() - and it works fine with Mason subrequests or recursive calls to an entirely different Mason interpreter. It just returns the value of a dynamically scoped variable that is set at the beginning of a Mason request. If you like that style, load Catalyst::Plugin::Singleton and enjoy. I don't but I'm not the arbiter of bad code :) Cool, that's exactly what I was hoping for. 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. 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. -- Matt S Trout Need help with your Catalyst or DBIx::Class project? Technical DirectorWant a managed development or deployment platform? Shadowcat Systems Ltd. Contact mst (at) shadowcatsystems.co.uk for a quote http://chainsawblues.vox.com/ http://www.shadowcatsystems.co.uk/ ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] plugins; was Re: debug mode
On Thu, 7 Jun 2007, Matt S Trout wrote: 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. I agree. A singleton is basically a _very_ thin mask for a global. 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. Basically, what Catalyst seems to have is a sort of listener type of pattern, but listening is implicit rather than explicit. It's a little weird and magical, but I think it's better than a singleton. I'm not sure it's the _best_ solution, as it still seems a little too arcane for my tastes. Also, the docs for this feature could be clearer. I've never quite grokked what makes Catalyst decide to look for this method in a class. Is it simply _any_ class that's passed in the import list to use Catalyst? The docs refer to a Catalyst component, but this isn't really well-defined. I know it includes models, views, and controllers, but are plugins also components? Also, I know weaken() came up in this discussion. It'd be good if the docs addressed exactly when this is needed and give an example. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/ ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] plugins; was Re: debug mode
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'm not sure about the action at a distance' thing. Also seems pretty equivalent. You have this outer context thingy making a call into a magical model method so it can add a singleton to itself. ;-) In terms of testing, seems like the singleton is a bit better since you have no ACCEPT_CONTEXT method to test. 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 agree that having the singleton does make it easier to couple too tightly though. ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] plugins; was Re: debug mode
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. 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. 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. -- Matt S Trout Need help with your Catalyst or DBIx::Class project? Technical DirectorWant a managed development or deployment platform? Shadowcat Systems Ltd. Contact mst (at) shadowcatsystems.co.uk for a quote http://chainsawblues.vox.com/ http://www.shadowcatsystems.co.uk/ ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] plugins; was Re: debug mode
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: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
