Frank, Yeah, for browsing Smalltalk repos on github itself, I figured that an Amber app would be the way to go ...then you could have a "real" code browser with senders implementers, etc.... and the same code could run in a pharo image to browse unloaded repos from github or disk ...
Just a simple matter of putting tooling in place:) Dale On Fri, Mar 7, 2014 at 1:34 AM, Frank Shearar <frank.shea...@gmail.com>wrote: > On 6 March 2014 20:18, 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. > > > > 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 ... > > Another huge strength with versioning per method (and one of the main > reasons I don't complain too loudly about the uselessness of GitHub in > viewing code when doing this) is also that you never ever have to try > merge two methods that two different commits have put in the same > place, and the diff algorithm has decided to _interleave_ the methods. > Fun times! > > frank > > > 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 > > > > > >
