Re: Renaming src/

[Rik]

On 08/14/2012 01:39 PM, address@hidden wrote:
> Message: 6
> Date: Tue, 14 Aug 2012 13:54:27 -0500
> From: Daniel J Sebald <address@hidden>
> To: "Robert T. Short" <address@hidden>
> Cc: address@hidden
> Subject: Re: Rename src/
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> On 08/14/2012 12:46 PM, Robert T. Short wrote:
>> > On 08/14/2012 10:43 AM, Michael D Godfrey wrote:
>>> >> On 08/14/2012 12:39 PM, Jordi Guti?rrez Hermoso wrote:
>>>> >>> One last thing in the source tree reorganisation. Can we rename src/ 
>>>> >>> to interp/?
>>>> >>>
>>>> >>> - Jordi G. H.
>>> >> I vote yes.:-)
>> > So if we are going to make descriptive names, why not really get
>> > descriptive - interpreter instead of interp, libfortran instead of
>> > libfort, etc.?  Long names inflict minor inconvenience I suppose, but
>> > shortened names seems so, well, FORTRAN and 1960.
> An emphatic "no" on that idea.  I go with historic precedent.  The 
> reason these condensed names came about is that it cuts down on 
> keystrokes and length of names.  The latter was important in 1960 when 
> memory and screen size was limited, but the former point on keystrokes 
> still holds.  I realize there is tab-completion for a lot of things 
> these days, but still there is benefit to adhering to convention.  "src" 
> is a common condensation in the linux tree.  "usr", "src", "etc" are 
> ingrained symbols that make a programmer efficient, just like memorized 
> control sequences for a favorite editor.  It doesn't mean much to 
> someone who's not a programmer at heart and just pecks around on the 
> keyboard, but for folks who do programming 24+/7+ it makes a difference. 
>   (I'm not one them, but hold that view out of deference.)
I agree.  I  spend a lot of time roaming the code tree and long names, even
a few extra characters, become a pain after a while.
>
> Along that same lines, I would avoid spaces in directories for sure. 
> Also avoid directory names that have several letters in common at the 
> front, such as "interp-core" and "interpfcn".  Having such things makes 
> tab completion or searching clumsy at times.  If the "interp" must be a 
> commonality, my feeling is to then make a directory "interp" with 
> subdirectories "core" and "fcn".  Most of all, be consistent.  For 
> example, "corefcn", "interp-core", "interpfcn" has some inconsistencies 
> in the sense that
I agree here too.  I'm already finding that not being able to tab complete
interp-core vs. interpfcn is a problem.
>
> 1) Some directories have hyphenation, some don't.
> 2) The "fcn" is almost a redundancy, unless the implication is that 
> there is some function in Octave called "core" and some function inside 
> Octave called "interp".  Otherwise, if it just means inside the 
> directory are some functions related to "core", for example, then what 
> else would the programmer think is in there if it were just "src/core"?
> 3) There's "corefcn", there's "interpfcn", and then there's a 
> combination of the two "interp-core".  Perhaps that's correct, but on 
> first read it makes one pause.
There are some reasons for this.  "interp-core" is for code which is at the
heart of the interpreter and which does not export any user visible
functions.  "interpfcn" is for code that has functions the user can see
such as warning() or dbstop().  "corefcn" is for functions which are at the
heart of mathematical analysis, such as inv() or eig(), but which aren't
related to the interpreter.  Lastly "dldfcn" is for dynamically loaded
functions.  I'm open to a better naming scheme as long as the distinctions
that have currently been made can still be made.

The other hyphenated directories--"octave-value", "template-inst",
"parse-tree"--come from trying to be specific about what is in them without
using CamelCase.  Since spaces aren't good, and jwe prefers hyphens over
underscores, that is what we came up with.

--Rik