Re: what do you want to do with server-side JavaScript
Kris Kowal
> I wish that instead of a "Function.prototype" property there was a
> "Function.prototypes" array-valued property containing multiple
> prototype objects. I think that would have been my ES4.
In Python, this is established with a "method resolution order"
attribute of classes. This is a list of "prototypes", the first of
which that provides a particular method intercepts a method call (much
like scope chain and prototype chain symbol lookup). It also permits
functions like "super" to work. In Chiron, types are generated from
lambdas with a "type" function that returns an instance factory
function (same as a native JavaScript type except you don't use the
"new" keyword), and this type has a getMro() method and instances have
a getSuper(Type) method that uses the MRO to get the interface
"snapshot" from before your own type constructor ran (permitting you
to call a super-function from a polymorphic/overridden function).
Additionally, types support "mixins", in the Python sense, so
getSuper() will work even if there's an interesting, albeit acyclic
(monotonic), type graph.
One problem with this system is it's pretty heavy, and not really
prototypical. This style of programming works great for languages
like Python, but it's sometimes noticeably slower that prototype
programming on the client side. So, we're beset with a trade-off
between power/flexibility/reusability and performance. I don't expect
this trade-off to last once Mozilla's *Monkey projects reach fruition,
but until then, working with a comprehensive type system might be
restricted to the purview of server-side JavaScript. I've been
working with these kinds of constructs on the client side for about a
year now, and I'm beginning to like JavaScript more than Python
because of their orthogonality and the flexibility of JavaScript's
explicit local scope declarations (var) opposed to Python's implicit
(by assignment) variable scope.
> Going from browser UI to database stored procedures in one language
> would be quite interesting. There is at least one project for
> PostgreSQL with JavaScript.
In general, I agree that the central tenet of this project should be
maximizing the synergy and reusability of code in one language and API
for the web platform. I also believe that using the right tool for
the right job is an important focus of energy for individual
developers. At the moment, there is no single language and library
that is the right tool for all web development jobs, and there won't
be, but XJS has a chance of reducing the gap.
Kris Kowal