singingfish’s Neighborhood

While trying to finish up my thoughts of the followup to "Does Anyone Else Hate the Stash?" one issue that I'm been grappling with is the relationship between using the stash as secondary global namespace and the way I've seen people use the stash as a sort of messaging system to methods called via $c->forward and the like.  I guess part of what troubles me here is how doing so seems to bust encapsulation, using the stash as a sort of 'pass by reference' system that reminds more of Perl 4 then where we are at now.  I've seen code that forwarded to a method, where the target method expected certain things in the stash but with no interface to really tell you want was expected.  That code would forward to other code that expected different things in the stash.  And all along all these forwards, stuff gets dropped in and mangled in the stash so by the time it returns from the initial ->forward I really have no idea what is in the stash anymore.

Is this a problem or am I just being too controlling :)  Tell me!

So, tell me what you are using forward for, and how you use (or don't use) the stash when doing so.  I won't pollute your thoughts on the matter with mine until I've heard from you first :)

And another thing while I'm typing, it seems like all my most popular blog posts contain the word 'Hate" in the title.  I may be concerned.

Thanks!

Rainbow taken from the car as we were on the motorway between Penrith and Lancaster.

Now we discover that insane-o-cat likes to be carried around in a bag.

My Goddaughter enjoying kids TV on a very lazy Sunday morning.

Encounter with an obvious dosser-tastic youth on th train. there are many reasons to be distressed by what he was saying and wearing.

First hard frost of the season settles on Lancaster after a clear night.

OOPSLA 2009 happened a few weeks ago. OOPSLA stands for Object-Oriented Programming, Systems, Languages & Applications and I've always been quite interested in the conference. The proceedings of the conference aren't put online, but I've managed to find two interesting papers:

A Market-Based Approach to Software Evolution (PDF) tries to imagine an open market which is targetted around fixing bugs and improving software. It's quite interesting as it's quite similar to a proposal from Nicholas on spending other people's money. The authors point out many potential flaws.

The Commenting Practice of Open Source (PDF) analyses projects on Ohloh and tries to spot commenting trends. "We find that comment density is independent of team and project size", but they find that it varies from language to language. "Java has the highest mean of comment lines per source lines at.. one comment line for three source code lines" and "Perl has the lowest mean with.. one comment line for nine source code lines". They list as future work to find out why this might be the case.

A few months ago, when discussing how to support the 'darkpan' (what Perl programmers call the vast body of perl code floating around the internet or in private companies that we know nothing about) I suggested leveraging the vast CPAN distribution system as a sort of continuous integration/build service which we could offer as a for pay service to companies using Perl.  This would have the dual benefit of encouraging corporations to package up their perl code properly (ie as  CPAN module with a Makefile.PL, etc) and could help raise money to sponser Perl development.

What I'm thinking about would be similar to a ruby only service I noticed: http://runcoderun.com

Check that out and let me know what you think.  What kind of services would the 'quasipan' be required to offer in order to entice companies into paying for it?  For example, what do you think of the idea of being able to build a EC2 or other cloud image type from a base OS that intergrate any given set of CPAN and Darkcpan modules?  Like, "I want a virtualbox VM with Perl 5.10.1 on debian with git, postgresql and Catalyst preinstalled, although with my private repo of proprietary code?"

Well Perl Ironman Readers,

Based on the public and private comments from the previous blog I decided to go ahead and write something (I hope) cpan worthy.  It should show up shortly over here but until then you can check it out on github (or clone / offer improvements)

I'm not in love with the name.  If you have a better idea please speak up, but I don't like to let naming issues stop  me from publishing.

Thanks!

I find as part of my normal course of writing perl moose based code, I do the following quite often:

Basically I tend to use the above with a core application class that is delegating work to several other classes.  In the above case, my general Library Class contains a Album class (presumable your library would hold an album and perhaps several other things).  In my Application logic I'm going to be calling methods on Album which have been properly normalized to the class which attempt to encapsulate the problem domain it attempts to solve.

I find the above form, although a bit verbose, to give me a lot of flexibility, particularly when I bring the application model into Catalyst via something like Catalyst::Model::Adaptor, which let's me define all the args in the global catalyst configuration.  Also, for testing, it's nice to be able to override the default classes, swapping in say a Mock Object or similar for the purposes of test cases.

In general use this construct commonly to avoid hardcoding all the connections between the elements of my applications.

Usage might be like:

Although I as mentioned, typically I instantiate this via Catalyst or as part of a more complicated application using an inversion of control container like Bread::Board.