File Trees To Manage Code Discussion

Because of LimitsOfHierarchies, I believe that the existing hierarchical file systems are insufficient to manage the code of non-trivial applications. I would like to hear other opinions on this. However, most existing tools are hard-wired to work with treed files only. -- A RelationalWeenie

Should I assume that we're talking about TwoDimensionalTrees? here? Safe to assume that a BanyanTreeForest? model is not the idea?

  function A(...) {

function B(...) {...}

How does A know where to find B in an interpreted environment?

"Interpreted" language usually only refers to the back-end. Most interpreters parse as much text as they can, and build up the symbol table as they go. A has no problem finding B, as by the time A gets to run, B is already in the symbol table and is well-known. Most symbol tables are somewhat hierarchical (a symbol table can be an element of an enclosing symbol table, this is how nested lexical scopes are implemented), but this has nothing to do with the filesystem. If the language supports eval(), and the argument to eval cannot be pre-parsed; it is parsed when it is run.

Some interpreted languages will find B by searching first in current memory cache, then current application directory, then along the OS executable search $PATH, while others will require you supply a location or list of locations to test for the existence of B at run time.

{Maybe you should have a look at IntentionalProgramming. There all "symbols" are in a 'data base' and can be viewed and edited in different ways. I heard Outlook was built this way. -- GunnarZarncke}

Maybe that is the problem. If the language has its own "symbol table", then we have a OnceAndOnlyOnce sin with regard to the database. At least some of the symbols, such as function names, are already in a table if you use a RDBMS to manage code. If it was truly "device independent", when it could get function info and do name-space searches within the database (along with some caching).

Please go learn what a symbol table is before making suggestions on how they should work, because it's quite clear you don't know.

I suppose I am going to have to build a table-oriented interpreter to shut skeptics like you up. BTW, I never claimed a "symbol table" was a relational table. -- top

 gcc -c foo.c 
have it do
 <command to issue database query to retrieve source code> | gcc -c /dev/stdin
Similar tricks can be pulled in other languages.

The same tricks may not work for interpreted languages.

Hmmm. Since there are as many interpreted languages as there are file systems to house them (more, actually), what is it we're seeking here?

I want to manage source code in a RDBMS instead of a file system. Ideally, each function would be in a database record, but a consolation prize is having each module in a record. I generally use interpreted languages.

It seems to me that you are just trying to emulate PolyMorphism. This may be good if you don't want to mess around with an OO model for your data. But, the downside is having some messy SQL code deciding which function is really called, instead of a single and elegant call, and letting the compiler or runtime to decide which one is really called.

Why is it "PolyMorphism"?

Well, I guess that if this happens at compile time, it is just some way of conditional compilation. However, if you do this at runtime, you basically are applying different (but probably related, so the query has some sense) functions depending on the data, without going into a if or switch statement (in C and the like) to determine the function. That I see as PolyMorphism (in a broad sense).

>>My goal here to improve human management of code. swing-developer replies: this is a jolly good idea, and an RDBMS is a natural fit. There's a lot of information which is lost when code is edited, and if the editing of code had as a side effect a transaction within a database, then that act of editing itself, complete with some aspects of the intent of the human who did the edit (let's start there at least) could become a first class citizen. That's very interesting information. Of course, I myself could never stand to give a reason why I had committed something to version control and no programmer is going to accompany every edit with a little story about what they were thinking, but that's not required. Performing refactorings like "rename variable" or "extract method" have built into them, if they're executed as committed macros (which they all are nowadays) what that aspect of intention was.

It may not sound like an interesting thing to know that such and such edit was performed as part of, say, a global rename of some variable, but that information identifies the persistence of a thing, that variable, which otherwise might be missed. Identifying the persistence of things which may mutate forms over time is a first class Hard and Interesting problem that can be leveraged in very many ways.

As an example, in the case of "extract method", it would be hard to know that the appearance of some lines of code that used to appear in Method A but are now missing from that method yet appear in Method B is definitely an example of "extract method" without recording the execution of extract method explicitly.

The utility of the RDBMS in this scheme is it provides a gatekeeper through which all edits must pass thus providing a way to know when any line of code has been edited, which in turn permits arbitrary code to be run in response. As it is now, there really is no centralized mechanism that distributes the fact of the event of an edit. Furthermore, edits can come from any number of processes or actors. To obtain global knowledge of all edits, you could try to write document listeners for each file, and integrate that into the IDE (if you have access to the source), but without the cooperation of not just the IDE but all plugin writers who cause edits to occur also, you can't know what the intentional semantics (a made up term whose meaning should be clear within the context of this post) of an edit were. Writing listeners that listen to every file in a project is No Fun. Trying to interpret the meaning of those edits just from the changes they inflict on a file is Even Less Fun.

Moved from HowCanSomethingBeSuperGreatWithoutProducingExternalEvidence:

The RelProject implementation of TutorialDee stores all user-defined code definitions within a relational database. All code resides in the database as source. There is no code repository outside of the database. Upon the first invocation of a given function, its source code is looked up in the database, compiled to an executable form, the executable form is cached, and finally it is executed. Subsequent invocations execute the cached version.

Related: TableOrientedCodeManagement

Perhaps move all this to TableMantraTakenToExtreme?

See also: WebScriptFileStructure, SeparationAndGroupingAreArchaicConcepts

CategorySourceManagement, CategoryInfoPackaging

EditText of this page (last edited July 29, 2012) or FindPage with title or text search