Stephan,

The reason that we have the granularity of a file per method is to leverage git's history/tracking facilities on a per method basis.

At this level of granularity, you can move a method around in the package structure and git will maintain the method modification history because git treats these as a file rename and git is very good at tracking file renames ...

So you can use "blame" to view a line by line history of the method modifications ...

If one starts clumping methods into files, then you lose all method history when it moves from one clump to another ...

Dale

On Thu, Mar 6, 2014 at 9:03 AM, Stephan Eggermont <stephan@stack.nl> wrote:

Max wrote

>In my opinion there are other factors, like readability, maintenance etc, that are maybe more important than speed.

I’m not totally convinced. The readability from the outside is limited by having one file per method.
Mainstream tooling assumes one file per class. The emails from github to this list are a good example
of the usability problems that leads to. I don’t want to suggest switching to a larger granularity, as that
leads to another set of problems.

My point was more if we could mostly avoid the source view, and directly work with the archive.
Why is working with single files fastest?

Stephan