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.
Import. What language structures are there to allow integration with
other languages? Or does the spec assume that everything is in
(Javascript|
Ecmascript|JScript|ES4|ActionScript|Script++|Whateveranyonewantstocallit)?
I found nothing in the spec. Maybe
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?
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
(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:
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.
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.
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.
1. Import. What language structures are there to allow integration with
other languages? Or does the spec assume that everything is in
(Javascript|
Ecmascript|JScript|ES4|ActionScript|Script++|Whateveranyonewantstocallit)?
I found nothing in the spec. Maybe
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
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.
Import. What language structures are there to allow integration with other languages? Or does the spec assume that everything is in (Javascript| Ecmascript|JScript|ES4|ActionScript|Script++|Whateveranyonewantstocallit)? I found nothing in the spec. Maybe
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?
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 (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:
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.
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.