A few questions & some observations

Mon Oct 29 06:04:29 PDT 2007

Hi List,

Firstly, thank you TG1 for your very hard work on the spec. It strikes 
me as an excellent bit of work.

Then, taking the list back to discussion of technical issues, I've a few 
questions as a result of the Overview. And then a couple of observations.

2. Isolation. Eval environment & isolated inner environments. ES4 
strikes me as a very good server-side language, and what follows is 
motivated by this. First two use cases & I'm sure I can think of more:
a) In an MVC structure, it's ever so nice to be able to express the View 
in a small template language. This makes the View portion very much more 
malleable and lets us skin applications. But why use a small templating 
language? The scripting language we use for the rest is perfectly good, 
except that because we give less trusted users access to the View 
templating language, we need to enforce security boundaries. If eval() 
was isolated or if we could ensure that a function had no write access 
to variables outside its immediate innermost scope then we might be able 
to use the scripting language itself instead of a small language. We 
would need isolation + a trusted interface to the isolated portion.
b) In a server side environment we tyically expend a lot of energy 
separating clean and tainted user data. With isolation facilities built 
into the language, the language could ensure that wilful programmer 
stupidity, rather than programmer mistakes are the cause of security 
lapses. A expample of this sort of isolation is the Perl tainted 
variable concept. Or the language could accomplish the same through 
isolation of user input + a trusted interface to the isolated portion.
So my question: what isolation and security facilities are built into ES4?

3. Structure of packages and program units. This wasn't clear to me in 
the Overview. Are program units made up of packages? Or are packages 
made of program units? Where do files come into the picture? Reading the 
spec proposal 
(http://wiki.ecmascript.org/doku.php?id=proposals:program_units) made it 
clearer. I think the intention to be able to load parts of the program 
as needed and that units enclosed packages. But can a package be 
implemented in 2 or more units? I think that the idea is to allow 
something similar to PHP, which has require 'filename', require_once 
'filename', include 'filename', and include_once 'filename', which does 
allow classes to be made from more than one file, and allows loading at 
runtime, and also allows variations at runtime because 'filename' can be 
a string. But it could be more like C# which allows the implementation 
of a namespace in more than one file, but not dynamic loading. And if 
it's like PHP,  how does use unit deal with the various cases? Is there 
a potential problem in strict mode, when type defintions for a variable 
is in one program unit and useage of that variable is in another? Is 
strict mode meant to verify through path analysis or just error because 
it's not immediately obvious. Can I do this and expect a working 
program... write to a file unitx.js and then immediately use unitx 
"unitx.js"? If use is equivalent to run-time eval then I'd say yes. If 
it's a compile-time eval then I'd say not. From the semantics in the 
proposal I think that wouldn't work.

And then observations:

1. IMO the null string rendering as = "null" is a language bug. Yes, 
it's been around since Netscape 2 beta. If TG1 is not willing to fix 
this now perhaps a pragma stating that null == "" would be a good idea? 
Or perhaps it could be part of Strict? This would give the option to 
transition to the more sane null to string in the future.

2. Unions. regarding the recent discussion. Obviously there's no right 
notation, but if you can transfer skills from one language to another, 
then that's a Good Thing in my book. This means that for unions (string 
| int) is better notation than (string, int). The same goes for all the 
other notations for annotated object types, annotated array types, 
parametrics etc - if you can find one that's transferrable which does 
not break existing language usage conventions, then that's better than 
inventing a new notation.

Jeff