Richard Uhler - 2007-09-08

Logged In: YES
user_id=1884147
Originator: YES

These are the bugs I'm talking about:

- (transfered) All operators should be changed to functions which take two pointer arguments and return a pointer argument.

- (transfered) Should Date.unexposed be inaccessable from library users? I could put all those functions in their own namespace via the function hack.
Maybe expose it, only call it Date.internal instead.

- We forget to check for an exception in almost every expression. Is there
a better way to do this? Use c++'s exception handling? (I'd rather not).

- const-ness has gone wild. Make every thing const that reasonably can
be from the bottom up. It may be a good idea to review why we do
const in the first place, and what it protects for and against.

- Now that we have gc, try to maintain as much type info as possible.
For example, don't use Value* when we could use an Object*. This goes
all the way to the parser too. An IDENTIFIER should be of type String*,
etc...

- Nothing should crash now. Nothing should assert now. We should be catching
everything with exceptions. And ideally printing a nice message and
stack trace...

- Attributes are very scary. Go through the Ecma spec grepping for
"attribute" everywhere. Make sure I got them all right. Write up
tests for all.

- We have 6 reduce/reduce from the parser. The bison docs says those are
almost surely bugs! Figure out what they are and how to fix them.
It's from FunctionDeclaration and FunctionExpression being exactly
the same in some cases. Figure out how to tell bison we always
want FunctionDeclarations if there is any ambiguity.

Now we have 8. Not sure what the two new ones are...
Now we have 10. Keep up man!
Now 18. My god!
21 and counting...

- Rather than having global objects for: null, undefined, true and false,
they should be static members of their respective classes.
TheGlobalObject should go away and be replaced by a Scope method
which returns that Scope's global object (follow the scope chain
to the root, which by definition is the global object).
And all the prototype objects should be static members of their
corresponding *Object classes, which should be created.

I'm thinking now that perhaps all the prototype objects should be
part of the JustObject class (it should be turned into a class) as
static members. Either that, or just their corresponding Object,
Boolean, String, etc... classes.

- I'm frightened now with the prototype stuff. There must be lots
of bugs. Do a code review to insure all objects get the right
values and prototypes.

- There's a bug in the Makefile somewhere. When I added VT_LIST, not everything
was updated that needed to be.

- dep.py doesn't recursively look through header files for additional
dependancies, like I think it should.

- Inclusion of the Type enums is not consistant. Should they be stored with
their corresponding class, or in their own file?
Certainly for OperatorType they need their own class. All currently
are their own class except for CompletionType. But when would you
use CompletionType without a Completion? When would you use
ValueType without a Value? When would you use HostValueType without
a HostValue? I'm thinking they should go in their corresponding files.
There's no rush though. It's not bad how it is now.