On 06.03.2014, at 21:18, Dale Henrichs <[email protected]> wrote:
> 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 … Ah, I knew I had forgotten something :D Thanks Dale > > Dale > > > > On Thu, Mar 6, 2014 at 9:03 AM, Stephan Eggermont <[email protected]> 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 >
