I hope that somebody will have a look at the newspeak library that abstract from the back-end storage because this is an interesting idea.
> > > On Thu, Mar 6, 2014 at 12:18 PM, 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. > > 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 <[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 > > > > > -- > best, > Eliot
