use Perl

More complex history (with multiple holes), can be reconstructed with the grafts file and git filter branch.

Secondly, note that I still haven't figured out a sane default for the tree importing WRT .gitignore. If there's a global gitignore in ~/.gitconfig then that gets applied (perhaps wrongly).

Many times people ship files they don't want in VCS and vice versa. Obviously for unshipped files there's nothing gitpan could do but in the other direction git filter branch would be useful for pruning out unwanted files.

another alternative is using interactive rebase to edit the gitpan imported commits that introduce the unwanted files (for instance for MANIFEST that would probably be the first one). git rm --cached MANIFEST && git commit --amend -C HEAD should do the trick. If there are any other versions of a file later in history that would result in an easy to resolve conflict.

Because you can always implement $customer->save in terms of a well factored interface, but going the other way is much harder.

The interface that T::B would present is just one facet (albeit a very important one). It used to be that the tradeoff was too much java style boilerplate or a god object, but Moose's handles feature lets you have a nice interface on the outside and flexibility without needing combinatorial explosion on the inside.

The point is that for 99% of the usage you can still use T::B because that "too much" is handy, but when you want to output a differfent test format or output TAP without T::B.

But note that I'm also not saying that the remaining 1% of the use cases justify another API. That's just an added bonus. The real benefit is that a clean separation is forced that makes such code generally last much longer, which would mean that developing a better T::B would be a much smaller effort than developing a full stack.

Isn't that pretty much the same reason for TAP::Parser's design?

Though that wasn't the main point of the post, which was that if you just go about converting base classes to roles where you have recurrence of god objects, you will get god objects implemented with roles ;-)

As you showed, in real life lots of stuff that happens to be working probably shouldn't be. Many a time i find myself reading through old code and saying to myself something along the lines of "OH F*ET!$%*Y HOW THE H*U$!(&Y DID THIS PIECE OF &$!(&!Y% EVER WORK TO BEGIN WITH?!!". Something like that would not be easy to transform and my statement doesn't really apply. Unfortunately real code has parts like this and that's just life.

The real thing I was getting at was that roles, though more reusable and generally safer, are still not a fundamental departure from a class like code reuse hierarchy. They provide saner defaults, but you can still make design mistakes that roles can't catch.

Personally I think delegates are a better solution for many of the things people use roles on a single object for. What I like about roles in this context is that they are much easier to move around and consume in different classes than base classes, so refactoring a single object into a delegate hierarchy is much easier and safer when you use them.

This is already being done, compiling for a VM that is a little more widely deployed than Parrot ;-)

bah, i meant attempts to *define*

I think Perl has continually defied these attempts to package patterns because of it's meta programmability.

Things we previously thought were not possible to package are now on CPAN as usable modules.

Design patterns are thus getting more and more refined, and in time converge simply with the best practices for the software that helps to implement them.

In the Java community metaprogramming is a much more difficult thing, so in order to produce extensible, reusable and clean code you need to have a much stricter methodology.

I was just commenting that the goals are similar to those of AOP, and that it might be worth to have a look at the prior art in that field.

Whether or not an IDE is necessary to use AOP is irrelevant. I've never used AOP (apart from playing with the Aspect module), but it was definitely interesting to learn why AOP is defined the way it is.

Your usage of roles in this case and AOP are very different implementations of a similar idea (that there are two "types" of code).

FWIW, Moose's method modifiers and their [ab]use in roles provides similar functionality to a very limited subset of AOP, where you opt in to accept point cuts, instead of just getting them randomly out of nowhere.

This distinction lies at the heart of aspect oriented programming, where the idea is that using declarative decorations you can add additional aspects without introducing the cross cutting concerns into the main flow (herein referred to as the "natural" code).

The general idea is that if the natural code is well factored then it is easy to use a hook based system to do things like passing around shadow parameters, wrapping with hooks, adding validation, etc.

AOP calls the "synthetic" code "advice". Advice is attached to code using point cuts, which are descriptions of the conditions for a the hook to be triggered. When the natural code executes and reaches a join point, a precondition described in a point cut, the advice is executed.

I started responding in comments yesterday, but moved it to a blog post when it grew long. Then it grew longer ;-)

Short story: I think moritz has hit the nail on the head, but I go into details about the ideas that dami, perigrin and hobbs commented about.

http://blog.woobling.org/2009/10/roles-and-delegates-and-refactoring.html

~/Documents

It would be interesting to see how many of these are reused storage allocated on pad variable introduction.

In principle the static overhead of PADLISTS, etc could be completely shared (once allocated they never change) but the actual SV bodies they store change all the time.

Maybe priming the callstack by invoking all of the CVs in order to share that stuff could be worth while, though it's probably not that much storage at the end of the day.

Secondly, Stefan O'Rear has been working on memory compaction, look at his stuff here: http://github.com/sorear

and of course there's the recent work trying to make the arenas more pluggable, it would be nice if eventually your efforts could be applied into making smarter allocations (increasing locality of reference between related SVs to reduce page faults or cache misses, for instance).

Though the other comments seem to address your issue, have you seen Enbugger?

Secondly, mentioning Devel::REPL also seems appropriate, though it isn't the same thing at all.

(and yes, i've received many many more contributions since I've switched, even if most of them did not become collaborators afterwords)

Putting aside the other technical superiorities, the entry barrier that Git removes is that of one off contributions.

Once you have an account it's easy to regularly contribute using SVN.

Git makes it easy to contribute to a project even if you've never contributed before, without knowing what the framework for contribution is, and without needing to be authorized.

It fills in the gap between emailing patches to someone (which is has technical annoyances but no administrative overhead) and giving commit access (which is technically streamlined but required administration) using its distributed nature to allow sending of patch files that have all the proper metadata to be cleanly applied.

This is taken further by hosting sites like github which let you create your own private repository from anyone else's repository, where you get full write access, so that people can pull changes from you.

Because of this getting one off fixes from non regular contributers is much lower overhead for both parties, and usually leads to more regular contributions later.

With subversion, even with a streamlined invite mechanism things would never be as smooth and safe.

You can make 'params' be a private attribute with a public init arg, and input a lazy readonly attributed whose builder method uses the private params.