Re: [cgiapp] Class::MOP? Really?
[EMAIL PROTECTED] wrote on 10/22/2007 05:53:19 PM: Thanx - but I assume you're being sarcastic :-(. -- Ron Savage I thought you put forth a very articulate post with solid reasons. Myself, I like reading about Perl modules because I like expanding my arsenal of techniques. I'm enjoying following the discussions from the last couple days. I hope for more. Todd # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] Class::MOP? Really?
Todd Ross wrote: Hi Todd Thanx - but I assume you're being sarcastic :-(. I thought you put forth a very articulate post with solid reasons. Myself, Thanx again. I like reading about Perl modules because I like expanding my arsenal of techniques. Me too. I'm enjoying following the discussions from the last couple days. I hope for more. Yes - to stop and think about issues is a nice change from coding... -- Ron Savage [EMAIL PROTECTED] http://savage.net.au/index.html # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] Class::MOP? Really?
Wow, your elegant argument has convinced me that all my issues are irrelevant and I will switch immediately. Ben On Oct 20, 2007, at 2:33 PM, Ron Savage wrote: Ben Hitz wrote: Hi Ben I am not a fan of inside-out objects in perl, because I have much old code which uses old-style hash objects. It's confusing to have two types (although technically usable). Your use of 'because' there is meaningless. Before someone adopts inside-out objects, /all/ their code is 'old- style etc'. And almost every line of code in CPAN is 'old-style'. So what :-)? This preponderance of old-style code, in itself, tells you nothing about whether or not inside-out objects are better, worse, or the same old same old. It simply means a vast amount of code was written before inside-out objects hit the big time. In other words, we use what we have learned. For those of us who are just about to try inside-out objects, without necessarily adopting them, it's a choice between conservatively sticking with old-style code or expending the effort to investigate something (inside-out objects in this case) which, if adopted, will actually require retraining the old brain a bit. This situation is similar to a job I've just applied for, where Perl Best Practices (PBP) is the mandatory way of writing code. I certainly won't have to make as many changes to adopt PDP as a lot of other programmers would (if I get the job), but I recognize there will be many little places where I'll have to stop and think about what I'm writing. And that's no bad thing, just an effort. And there's no escape from the fact that Perl, and software technology in general, are not static entities. They evolve, become more complex (perhaps unfortunately), and we can really only claim to be professional programmers if we are prepared to make some sort of effort to keep up-to-date (as distinct from mindlessly adopting the latest offerings from the loudest fanatics). We have been converting our hand-rolled Database API to DBIx::Class, which uses Class::Accessor (actually an extension written for DBIC) called Class:Accessor::Grouped and Class:C3 to dispatch. The fact that I prefer Rose to DBIC doesn't mean you should switch to copy me. Just investigate, cogitate, and choose the one you most like the look of. Before switching from Class::DBI to Rose, I read hundreds of msgs on the DBIC mailing list, but couldn't bring myself to feel enthusiastic about it. Adopting Rose required retraining myself, but after a very short while it just went Click! in a powerful way. So I asked myself - why is that? It's a feeling so it's difficult to articulate - but the word I now use is familiarity. Writing DBI code in Rose feels just like writing anything else in Perl. It (Rose) is a natural fit to Perl. But I'll say it again - just because it suits some of us doesn't mean it has to suit all of us. -- Ron Savage [EMAIL PROTECTED] http://savage.net.au/index.html # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## #### -- Ben Hitz Senior Scientific Programmer ** Saccharomyces Genome Database ** GO Consortium Stanford University ** [EMAIL PROTECTED] # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] Class::MOP? Really?
* Ricardo SIGNES [EMAIL PROTECTED] [2007-10-19T18:10:17] I see that the devel version of CGI::Application uses Class::MOP. Neat. Except it doesn't. I thought, Hey, I'll just send Mark a patch to remove this. I had an ancient checkout of CGI::Application, and I did a pull and saw: Thu Aug 17 08:31:34 EDT 2006 Mark Stosberg [EMAIL PROTECTED] * undo switch to Class::MOP ... Thu Aug 17 08:51:41 EDT 2006 Mark Stosberg [EMAIL PROTECTED] * Change prereq back to Class::ISA So, it's been 1.25yr since the last dev release -- in which time Class::MOP was removed. Yay for smallness! Mark -- what is blocking us from making a new dev release (or a new prod release)? -- rjbs # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] Class::MOP? Really?
I am not a fan of inside-out objects in perl, because I have much old code which uses old-style hash objects. It's confusing to have two types (although technically usable). We have been converting our hand-rolled Database API to DBIx::Class, which uses Class::Accessor (actually an extension written for DBIC) called Class:Accessor::Grouped and Class:C3 to dispatch. What do people think of this one? Ben -- Ben Hitz Senior Scientific Programmer ** Saccharomyces Genome Database ** GO Consortium Stanford University ** [EMAIL PROTECTED] On Oct 19, 2007, at 6:27 PM, Ron Savage wrote: Michael Peters wrote: Hi Michael This isn't a hey, Class::MOP is the new hotness! change, is it? I think this was a hey, Class::MOP is really cool. I bet it would make CGI::App much simpler...oh wait. Look how slow everything got!. And now we also have Look how big everything got!. So, pretty please, can we have a guarantee from the 'developer in quesiton' that Class::MOP will not be used? I've just finished reading Perl Best Practices by Damian Conway, and compiled a list of 14 class-helper type modules on CPAN (yes, I'm sure there are more), since I (too) have been wondering how my future work would develop. I realize there is no one perfect answer to this question, and Damian's module Class::Std has a long bug list on RT. Nevertheless, my vote would be either for Object::InsideOut or Class::Std, but only if it was necessary to use such a system in the first place. And is it necessary? This is the question. My feeling is: No, not for CGI::App. If you were to start another project, let's call it CGI::Framework, then sure, investigate such things, but I can't see how CGI::App needs any of this class/meta-class overhead. -- Ron Savage [EMAIL PROTECTED] http://savage.net.au/index.html # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## #### # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] Class::MOP? Really?
Ben Hitz wrote: We have been converting our hand-rolled Database API to DBIx::Class, which uses Class::Accessor (actually an extension written for DBIC) called Class:Accessor::Grouped and Class:C3 to dispatch. I am just learning DBIx::Class, also with the intent of using it to convert from a straight-DBI app. I gather it was written before Moose was production-ready; there is some talk now of reworking it to use Moose (and therefore Class::MOP), but I don't know how far along any of that is. Speaking of dispatch, Moosanites are recommending Roles over Multiple Inheritance, as well. Also, there is no reason one can't write a DBIC module that also uses Moose. But, getting back to the original topic, I agree with Ricardo that, since the name of the CGI::Application game is simplicity, adding any class meta-programming to its Perl 5 core doesn't really make sense, especially when speed and size are affected. Having said that, these modules (DBIC, Moose) are indeed useful tools, and I would also like to hear any stories people have about using them. I have always been skeptical about SQL-auto-generation systems, but I think the consensus is that DBIx::Class actually does ORM right. And, it lets you get to the guts and write SQL easily enough if/when you need to. I'll know more firsthand when I've written more code using it :) -- Dan # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] Class::MOP? Really?
Daniel Sterling wrote: Hi Daniel But, getting back to the original topic, I agree with Ricardo that, since the name of the CGI::Application game is simplicity, adding any class meta-programming to its Perl 5 core doesn't really make sense, especially when speed and size are affected. Exactly. Having said that, these modules (DBIC, Moose) are indeed useful tools, and I would also like to hear any stories people have about using them. I have always been skeptical about SQL-auto-generation systems, but I think the consensus is that DBIx::Class actually does ORM right. And, it lets you get to the guts and write SQL easily enough if/when you need to. There's a marvellous write-up of Moose here: http://www.iinteractive.com/moose/yapc_eu_2007_slides/start.html But I prefer Rose to DBIC. -- Ron Savage [EMAIL PROTECTED] http://savage.net.au/index.html # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] Class::MOP? Really?
Ben Hitz wrote: Hi Ben I am not a fan of inside-out objects in perl, because I have much old code which uses old-style hash objects. It's confusing to have two types (although technically usable). Your use of 'because' there is meaningless. Before someone adopts inside-out objects, /all/ their code is 'old-style etc'. And almost every line of code in CPAN is 'old-style'. So what :-)? This preponderance of old-style code, in itself, tells you nothing about whether or not inside-out objects are better, worse, or the same old same old. It simply means a vast amount of code was written before inside-out objects hit the big time. In other words, we use what we have learned. For those of us who are just about to try inside-out objects, without necessarily adopting them, it's a choice between conservatively sticking with old-style code or expending the effort to investigate something (inside-out objects in this case) which, if adopted, will actually require retraining the old brain a bit. This situation is similar to a job I've just applied for, where Perl Best Practices (PBP) is the mandatory way of writing code. I certainly won't have to make as many changes to adopt PDP as a lot of other programmers would (if I get the job), but I recognize there will be many little places where I'll have to stop and think about what I'm writing. And that's no bad thing, just an effort. And there's no escape from the fact that Perl, and software technology in general, are not static entities. They evolve, become more complex (perhaps unfortunately), and we can really only claim to be professional programmers if we are prepared to make some sort of effort to keep up-to-date (as distinct from mindlessly adopting the latest offerings from the loudest fanatics). We have been converting our hand-rolled Database API to DBIx::Class, which uses Class::Accessor (actually an extension written for DBIC) called Class:Accessor::Grouped and Class:C3 to dispatch. The fact that I prefer Rose to DBIC doesn't mean you should switch to copy me. Just investigate, cogitate, and choose the one you most like the look of. Before switching from Class::DBI to Rose, I read hundreds of msgs on the DBIC mailing list, but couldn't bring myself to feel enthusiastic about it. Adopting Rose required retraining myself, but after a very short while it just went Click! in a powerful way. So I asked myself - why is that? It's a feeling so it's difficult to articulate - but the word I now use is familiarity. Writing DBI code in Rose feels just like writing anything else in Perl. It (Rose) is a natural fit to Perl. But I'll say it again - just because it suits some of us doesn't mean it has to suit all of us. -- Ron Savage [EMAIL PROTECTED] http://savage.net.au/index.html # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
[cgiapp] Class::MOP? Really?
I see that the devel version of CGI::Application uses Class::MOP. Neat. Except... On my 5.8.8 install, loading CGI::Application's stable release adds about 300k to the resident size of my perl process. Loading metaclass.pm (of Class-MOP) adds another 2000k. In other words, moving from Class::ISA (which is core) to Class::MOP (which is not) not only expands the prereqs but also makes the smallest possible CGI::Application consume well over 7x the RAM. Is there any actual point to this change? Do we have plans to support alternate inheritence hierarchies for CGI::Application? Have any such been tested or planned? This isn't a hey, Class::MOP is the new hotness! change, is it? -- rjbs # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] Class::MOP? Really?
Michael Peters wrote: Hi Michael This isn't a hey, Class::MOP is the new hotness! change, is it? I think this was a hey, Class::MOP is really cool. I bet it would make CGI::App much simpler...oh wait. Look how slow everything got!. And now we also have Look how big everything got!. So, pretty please, can we have a guarantee from the 'developer in quesiton' that Class::MOP will not be used? I've just finished reading Perl Best Practices by Damian Conway, and compiled a list of 14 class-helper type modules on CPAN (yes, I'm sure there are more), since I (too) have been wondering how my future work would develop. I realize there is no one perfect answer to this question, and Damian's module Class::Std has a long bug list on RT. Nevertheless, my vote would be either for Object::InsideOut or Class::Std, but only if it was necessary to use such a system in the first place. And is it necessary? This is the question. My feeling is: No, not for CGI::App. If you were to start another project, let's call it CGI::Framework, then sure, investigate such things, but I can't see how CGI::App needs any of this class/meta-class overhead. -- Ron Savage [EMAIL PROTECTED] http://savage.net.au/index.html # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
