New review
Owner: dougkearns
Hopefully the changeset hash will actually be linked this time. If
not, it's the tip of the testing branch, presumably r4161.
I've been meaning to do this for a while. It allows case matching,
sorting, and auto completion options to be assigned on a per context
basis, with fine grained control. It also adds builtin regex support
to options since it's used fairly extensively. There are definitely
other options that would benefit from the regexlist type, if I can
dig them up. The interface (and perhaps the doc wording) is the only
place I'm really ambivalent.
--HG--
branch : testing
* Standard module format. All modules are explicitly declared
as modules, they're created via a constructor and
instantiated automatically. They're dependency aware. They
stringify properly.
* Classes are declared the same way (rather like Structs
already were). They also stringify properly. Plus, each
instance has a rather nifty closure member that closes all
of its methods around 'this', so you can pass them to map,
forEach, setTimeout, etc. Modules are themselves classes,
with a special metaclass, as it were.
* Doug Crockford is dead, metaphorically speaking.
Closure-based classes just don't fit into any of the common
JavaScript frameworks, and they're inefficient and
confusing. Now, all class and module members are accessed
explicitly via 'this', which makes it very clear that
they're class members and not (e.g.) local variables,
without anything nasty like Hungarian notation.
* Strictly one module per file. Classes that belong to a
module live in the same file.
* For the moment, there are quite a few utility functions
sitting in base.c, because my class implementation used
them, and I haven't had the time or inclination to sort them
out. I plan to reconcile them with the current mess that is
the util namespace.
* Changed bracing style.
