[webkit-dev] JavaScriptCore directory reorganization

[Geoffrey Garen]

On Jun 12, 2008, at 11:25 PM, Maciej Stachowiak wrote:

>
> Now that SquirrelFish has landed, I'd like to take a look at
> reorganizing JavaScriptCore's files and directories a bit.
>
> JavaScriptCore has the following subdirectories:
>
> API/
> VM/
> docs/
> icu/
> kjs/
> os-win32/
> pcre/
> profiler/
> tests/
> wtf/
>
> I see a few issues in this organization:
>

> 1) API and VM are all-caps, violating our usual all-lowercase scheme
> in JavaScriptCore and WebCore.

Agreed. Let's fix this.

> 2) The split between kjs and VM is ill-defined (kjs includes some
> compiler-related code, the includes some runtime classes)

Generally, the category kjs is not very useful anymore. It's not kjs  
anymore.

> 4) It's a little weird that the profiler has its own directory, but
> not the debugger.

Agreed.

> API --> rename to api

Agreed.

> profiler --> rename to tools and move debugger code here too

Agreed.

> kjs and VM --> reorganize according to runtime and then execution
> phases.

Sounds promising.

> Possible names for these directories:
>
> implementations of builtin types and runtime support code: runtime,
> builtins or library (runtime seems like the most popular choice)

I like runtime. Not everything will be builtins -- for example, the  
collector. Not everything will be explicitly available as a library to  
the JavaScript programmer -- for example, the Identifier class.

> lexer, parser and syntax tree classes (but not the emitCode
> functions): ast, syntax-tree, parser or frontend

I like parser. I don't like frontend because it's vague in the  
JavaScript context. (Maybe it wouldn't be vague in a compiler  
project.) I don't like ast because acronyms are not ideal for  
communication to people outside "the know." I don't like syntax-tree  
because it's more of a "how" statement than a "what" statement.

> CodeGenerator and related, plus various emitCode() functions (split
> out from their home in nodes.cpp): compiler, bytecompiler or codegen

I like compiler. I don't like bytecompiler because it's longer, and  
"byte" is not true. I don't like codegen because it's a little less of  
a standard term than "compiler."

> virtual machine and files that are purely about the bytecode execution
> model (such as CodeBlock) but not solely about code generation: vm

Agreed.

Thoughts on specific file moves:

kjs/
-----
SourceProvider.h, SourceRange.h : parser
AllInOneFile.cpp : global
*_instance : runtime
*_object : runtime
CallData.h : runtime
[cC]ollector* : runtime
CallData.h : runtime
CommonIdentifiers* : runtime
completion.h : runtime
config.h : global
ConstructData.h : runtime
create_hash_table : global?
d[D]* : runtime
ExecState.* : runtime
function* : runtime
grammar.y : parser
identifier* : runtime?
InitializeThreading* : runtime
internal* : runtime
interpreter* : runtime?
JS* : runtime
keywords.table : parser
LabelStack.h : compiler
list* : runtime
LocalStorageEntry.h : runtime
lookup* : runtime
object.*, value.* : runtime
operations* : runtime
property_* : runtime
PropertyNameArray* : runtime
protect.h : runtime
regexp* : runtime
scope* : runtime
SymbolTable.h : parser
types.h : the trash!
ustring* : runtime?
JSNotAnObject : runtime

compiler/
-------------
lexer* : parser
nodes* : parser
Parser* : parser

vm/
-----
JSPropertyNameIterator* : runtime

Geoff