On Thu, Mar 6, 2014 at 12:18 PM, Dale Henrichs < dale.henri...@gemtalksystems.com> 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. > the tail wags the dog. if the diff facilities in things like git were well-designed they'd be pluggable and allow one to parse files into meaningful chunks. But why do you need command-line diff tools? If one spends most of one's time in Pharo why not have diff tools there-in and avoid all these contortions to appease a primitive VCS? You're already hitting thins like filename length limits in the mapping, and you're hitting performance problems. The integration in Newspeak is quite different. It is file based, above mercurial (which makes no difference) but the tools one uses are in Newspeak. So mercurial really is just a back-end. Given that organizations and alphabetical order of selectors within protocols, classes within categories, etc, keeps things stable I find mercurial diffs are still pretty readable with file-specific command-line or GUI tools. Method-level granularity seems a very poor choice, IMNSHO. > > 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 <step...@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 >> > > -- best, Eliot
