On 07.03.2014, at 08:38, Pharo4Stef <[email protected]> wrote: > 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.
Noted. > >> >> >> 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 >
