> JavaScript needs a standard way to include other modules and for > those modules to live in discreet namespaces. There are easy ways > to do namespaces, but there's no standard programmatic way to load > a module (once!). This is really important, because server side apps > can include a lot of code and will likely mix and match parts that > meet those standard interfaces.
An include/load/require system is the essential ingredient in developing an extensible core interpreter. If a standard existed for how modules load, then more code could be shared.
Unfortunately, people disagree about how this should be done. Some like the shared global scope with a module in each child scope and/or namespace is the way to go. I think this is unnecessarily complex and that a single global scope like the browser has is the way to go and anything more should come from the language first.
A large discussion about these issues was had on the Helma NG group with three main participants. The lack of agreement on the module system issue was a complete spoiler. I believe this is *the* major issue to overcome.
Agreed, and from there package management is going to be a lot easier.
I'm of the belief that continuing on the JavaScript tradition of being
a first class language of the web that loading into a global space
should be the default (as it is today) with the onus of good
namespacing being the domain of the library authors.
>> JavaScript needs a standard way to include other modules and for
>> those modules to live in discreet namespaces. There are easy ways
>> to do namespaces, but there's no standard programmatic way to load
>> a module (once!). This is really important, because server side apps
>> can include a lot of code and will likely mix and match parts that
>> meet those standard interfaces.
> An include/load/require system is the essential ingredient in
> developing an extensible core interpreter. If a standard existed for
> how modules load, then more code could be shared.
> Unfortunately, people disagree about how this should be done. Some
> like the shared global scope with a module in each child scope and/or
> namespace is the way to go. I think this is unnecessarily complex and
> that a single global scope like the browser has is the way to go and
> anything more should come from the language first.
> A large discussion about these issues was had on the Helma NG group
> with three main participants. The lack of agreement on the module
> system issue was a complete spoiler. I believe this is *the* major
> issue to overcome.
> A large discussion about these issues was had on the Helma NG group > with three main participants. The lack of agreement on the module > system issue was a complete spoiler. I believe this is *the* major > issue to overcome.
Do you have a pointer to it? That way we could read up beforehand and avoid going through the same issues :)
On Jan 29, 4:20 pm, Brian LeRoux <brian.ler...@gmail.com> wrote:
> Agreed, and from there package management is going to be a lot easier.
I almost wrote the same thing. A package system (CPAN and apt
inspired) is the second thing I worked on for my server-side system. I
don't think a package distribution system has any issues that are as
"hot button" as the module loading issue has.
> I'm of the belief that continuing on the JavaScript tradition of being
> a first class language of the web that loading into a global space
> should be the default (as it is today) with the onus of good
> namespacing being the domain of the library authors.
I agree. It is the way the language is and we have already discovered
ways for how to deal with the problems of a global namespace.
On Jan 29, 4:24 pm, Robin Berjon <robin.ber...@gmail.com> wrote:
> On Jan 30, 2009, at 01:12 , Peter Michaux wrote:
> > A large discussion about these issues was had on the Helma NG group
> > with three main participants. The lack of agreement on the module
> > system issue was a complete spoiler. I believe this is *the* major
> > issue to overcome.
> Do you have a pointer to it? That way we could read up beforehand and
> avoid going through the same issues :)
Ow. I really don't agree :/ Having said that, I'll take a double helping of
global namespace pollution gladly any day over not getting anywhere :)
In my experience (again, only either hopping on random code on disaster area
projects or using Dojo) is that a short namespaced object hierarchy for
different functions has the benefit of being very clear. Putting everything
in global is a bit like having indexOf in the global namespace instead of on
the String object.
Also, using namespaced object does the obvious; no collission of variable of
function names, or the more probably mistaken one function for another with
a similar sounding name.
> On Jan 29, 4:20 pm, Brian LeRoux <brian.ler...@gmail.com> wrote:
> > Agreed, and from there package management is going to be a lot easier.
> I almost wrote the same thing. A package system (CPAN and apt
> inspired) is the second thing I worked on for my server-side system. I
> don't think a package distribution system has any issues that are as
> "hot button" as the module loading issue has.
> > I'm of the belief that continuing on the JavaScript tradition of being
> > a first class language of the web that loading into a global space
> > should be the default (as it is today) with the onus of good
> > namespacing being the domain of the library authors.
> I agree. It is the way the language is and we have already discovered
> ways for how to deal with the problems of a global namespace.
On Thu, Jan 29, 2009 at 9:47 PM, Peter Svensson <psvens...@gmail.com> wrote: > Ow. I really don't agree :/ Having said that, I'll take a double helping of > global namespace pollution gladly any day over not getting anywhere :) > In my experience (again, only either hopping on random code on disaster area > projects or using Dojo) is that a short namespaced object hierarchy for > different functions has the benefit of being very clear. Putting everything > in global is a bit like having indexOf in the global namespace instead of on > the String object.
> Also, using namespaced object does the obvious; no collission of variable of > function names, or the more probably mistaken one function for another with > a similar sounding name.
> I'd rather see;
> ssjs.file.open() > ssjs.foo.openup()
> than
> open() > openup()
This is not the difference folks usually mean when they talk about namespaces and module loading systems. What you are showing is simulating namespaces by using an object hierarchy in a global namespace system. It works in the browser and would work fine in a server-side system with a global namespace. I'm in favor of this type of system (though see ssjs_file_open as better than ssjs.file.open in several ways). These types of namespacing strategies are based on convention.
When folks talk about "real" namespaces they are usually meaning systems where code from one namespace has a limited, controlled channel of interaction with objects from another namespace. There is language or host support to assist or support the idea of namespaces. From what I've seen on the ECMAScript mailing list, this sort of system has been proposed and rejected (at least for now) from ECMAScript.
Then I stand happily corrected :)
Though, concatenating the names in a simulated object hierarchy give nothing
of the benefits of having an actual hierarchy and you're still using one, so
..
Cheers,
PS
On Fri, Jan 30, 2009 at 8:12 AM, Peter Michaux <petermich...@gmail.com>wrote:
> On Thu, Jan 29, 2009 at 9:47 PM, Peter Svensson <psvens...@gmail.com>
> wrote:
> > Ow. I really don't agree :/ Having said that, I'll take a double helping
> of
> > global namespace pollution gladly any day over not getting anywhere :)
> > In my experience (again, only either hopping on random code on disaster
> area
> > projects or using Dojo) is that a short namespaced object hierarchy for
> > different functions has the benefit of being very clear. Putting
> everything
> > in global is a bit like having indexOf in the global namespace instead of
> on
> > the String object.
> > Also, using namespaced object does the obvious; no collission of variable
> of
> > function names, or the more probably mistaken one function for another
> with
> > a similar sounding name.
> > I'd rather see;
> > ssjs.file.open()
> > ssjs.foo.openup()
> > than
> > open()
> > openup()
> This is not the difference folks usually mean when they talk about
> namespaces and module loading systems. What you are showing is
> simulating namespaces by using an object hierarchy in a global
> namespace system. It works in the browser and would work fine in a
> server-side system with a global namespace. I'm in favor of this type
> of system (though see ssjs_file_open as better than ssjs.file.open in
> several ways). These types of namespacing strategies are based on
> convention.
> When folks talk about "real" namespaces they are usually meaning
> systems where code from one namespace has a limited, controlled
> channel of interaction with objects from another namespace. There is
> language or host support to assist or support the idea of namespaces.
> From what I've seen on the ECMAScript mailing list, this sort of
> system has been proposed and rejected (at least for now) from
> ECMAScript.
You mention "open()" and "ssjs.file.open()" as possibilities, but you
left out my preference: "file.open()". I think it's perfectly
reasonable to have a few standard objects in the global scope, like
"File", "Socket", "require", etc.
Here's why:
1) While I do think *libraries* of code should be "namespaced", I
don't think that's necessary for what we're trying to do here. In the
browser XMLHttpRequest is a top level object. I'd say this project is
more like adding XMLHttpRequest to JavaScript than writing a library.
2) It's essentially what Ruby, Python, and many other languages do.
You usually don't see things like "Ruby.File.open()".
If we want this to be a standard (de facto or otherwise) we have to
act like it's a standard. Using "ssjs.File" sends the message that
it's not *really* the standard, it's just part of this "ssjs" thing
(also, I think ssjs is a misleading name, since you'll be able to use
it for things other than servers)
3) Some command line JS interpreters already come with a File object,
but they all vary slightly in how they work. Hopefully this project
will standardize them, not augment them. Having "File" and "ssjs.File"
is just confusing.
4) If you force all 3rd party libraries loaded through the package
system to also be part of this "ssjs" namespace, you're not fixing the
collision problem, you're just moving it down one layer.
5) Accessing "ssjs.File" is slightly slower than "File". Probably not
a big deal though.
That's my 2˘
-Tom
On Jan 29, 9:47 pm, Peter Svensson <psvens...@gmail.com> wrote:
> Ow. I really don't agree :/ Having said that, I'll take a double helping of
> global namespace pollution gladly any day over not getting anywhere :)
> In my experience (again, only either hopping on random code on disaster area
> projects or using Dojo) is that a short namespaced object hierarchy for
> different functions has the benefit of being very clear. Putting everything
> in global is a bit like having indexOf in the global namespace instead of on
> the String object.
> Also, using namespaced object does the obvious; no collission of variable of
> function names, or the more probably mistaken one function for another with
> a similar sounding name.
> On Fri, Jan 30, 2009 at 1:34 AM, Peter Michaux <petermich...@gmail.com>wrote:
> > On Jan 29, 4:20 pm, Brian LeRoux <brian.ler...@gmail.com> wrote:
> > > Agreed, and from there package management is going to be a lot easier.
> > I almost wrote the same thing. A package system (CPAN and apt
> > inspired) is the second thing I worked on for my server-side system. I
> > don't think a package distribution system has any issues that are as
> > "hot button" as the module loading issue has.
> > > I'm of the belief that continuing on the JavaScript tradition of being
> > > a first class language of the web that loading into a global space
> > > should be the default (as it is today) with the onus of good
> > > namespacing being the domain of the library authors.
> > I agree. It is the way the language is and we have already discovered
> > ways for how to deal with the problems of a global namespace.
Thanks for giving me another angle to see this from, Tom.
I agree with you that if this is going to be _the_ standard Server-Side
JavaScript definition, then having an extra level of namespace is of no real
use. I think I was mainly trying to emphasize the use of namespacing objects
in general, instead of concatenated function names as namespace.
On Fri, Jan 30, 2009 at 12:17 PM, Tom Robinson <tlrobin...@gmail.com> wrote:
> You mention "open()" and "ssjs.file.open()" as possibilities, but you
> left out my preference: "file.open()". I think it's perfectly
> reasonable to have a few standard objects in the global scope, like
> "File", "Socket", "require", etc.
> Here's why:
> 1) While I do think *libraries* of code should be "namespaced", I
> don't think that's necessary for what we're trying to do here. In the
> browser XMLHttpRequest is a top level object. I'd say this project is
> more like adding XMLHttpRequest to JavaScript than writing a library.
> 2) It's essentially what Ruby, Python, and many other languages do.
> You usually don't see things like "Ruby.File.open()".
> If we want this to be a standard (de facto or otherwise) we have to
> act like it's a standard. Using "ssjs.File" sends the message that
> it's not *really* the standard, it's just part of this "ssjs" thing
> (also, I think ssjs is a misleading name, since you'll be able to use
> it for things other than servers)
> 3) Some command line JS interpreters already come with a File object,
> but they all vary slightly in how they work. Hopefully this project
> will standardize them, not augment them. Having "File" and "ssjs.File"
> is just confusing.
> 4) If you force all 3rd party libraries loaded through the package
> system to also be part of this "ssjs" namespace, you're not fixing the
> collision problem, you're just moving it down one layer.
> 5) Accessing "ssjs.File" is slightly slower than "File". Probably not
> a big deal though.
> That's my 2˘
> -Tom
> On Jan 29, 9:47 pm, Peter Svensson <psvens...@gmail.com> wrote:
> > Ow. I really don't agree :/ Having said that, I'll take a double helping
> of
> > global namespace pollution gladly any day over not getting anywhere :)
> > In my experience (again, only either hopping on random code on disaster
> area
> > projects or using Dojo) is that a short namespaced object hierarchy for
> > different functions has the benefit of being very clear. Putting
> everything
> > in global is a bit like having indexOf in the global namespace instead of
> on
> > the String object.
> > Also, using namespaced object does the obvious; no collission of variable
> of
> > function names, or the more probably mistaken one function for another
> with
> > a similar sounding name.
> > On Fri, Jan 30, 2009 at 1:34 AM, Peter Michaux <petermich...@gmail.com
> >wrote:
> > > On Jan 29, 4:20 pm, Brian LeRoux <brian.ler...@gmail.com> wrote:
> > > > Agreed, and from there package management is going to be a lot
> easier.
> > > I almost wrote the same thing. A package system (CPAN and apt
> > > inspired) is the second thing I worked on for my server-side system. I
> > > don't think a package distribution system has any issues that are as
> > > "hot button" as the module loading issue has.
> > > > I'm of the belief that continuing on the JavaScript tradition of
> being
> > > > a first class language of the web that loading into a global space
> > > > should be the default (as it is today) with the onus of good
> > > > namespacing being the domain of the library authors.
> > > I agree. It is the way the language is and we have already discovered
> > > ways for how to deal with the problems of a global namespace.
> 2) It's essentially what Ruby, Python, and many other languages do. > You usually don't see things like "Ruby.File.open()". > 3) Some command line JS interpreters already come with a File object, > but they all vary slightly in how they work. Hopefully this project > will standardize them, not augment them. Having "File" and "ssjs.File" > is just confusing.
I don't agree there. Python does that because there's only one Python interpreter. (Well, there are others, but they're explicitly compatible with CPython.) We have multiple incompatible interpreters. If there's going to be a global File object then we either wait for all the interpreters to implement it, or we implement it ourselves as a wrapper on top of whichever interpreter you're on. As you say, some interpreters already come with a File object, but the whole point of standardising an API, to my mind, is to make sure you can write SSJS to one API and not many. If you're using ssjs.File then you *know* that it's the standard file object. If you're using File, then you don't know whether it's the SSJS file object or the interpreter's file object. Worse, if we override an existing global File with our global File then anyone who *wants* to make their project interpreter-dependent is out of luck, because we've overridden the interpreter's API.
> 4) If you force all 3rd party libraries loaded through the package > system to also be part of this "ssjs" namespace, you're not fixing the > collision problem, you're just moving it down one layer.
I don't think that's a good idea (it's certainly not what I'm proposing). SSJS would be the anointed, simple, API that does the basics. Other libraries can depend on it if they want to, but I don't think that they're part of it.
I must say, I'm personally for the top level objects in global. An
ssjs.* object would "smell" too much like a library or framework.
This being a spec, means that whoever wants a compatible interpreter
will have to implement it to be so, or just stay incompatible, making
the overriding problem a non-issue. Patches can be submitted for the
different opensource projectes and the closedsource world will just
have to make do.
The need for a standard is exactly so people can follow it and not the
other way around.
On Fri, Jan 30, 2009 at 11:48 AM, Stuart Langridge <s...@kryogenix.org> wrote:
>> 2) It's essentially what Ruby, Python, and many other languages do.
>> You usually don't see things like "Ruby.File.open()".
>> 3) Some command line JS interpreters already come with a File object,
>> but they all vary slightly in how they work. Hopefully this project
>> will standardize them, not augment them. Having "File" and "ssjs.File"
>> is just confusing.
> I don't agree there. Python does that because there's only one Python
> interpreter. (Well, there are others, but they're explicitly
> compatible with CPython.) We have multiple incompatible interpreters.
> If there's going to be a global File object then we either wait for
> all the interpreters to implement it, or we implement it ourselves as
> a wrapper on top of whichever interpreter you're on. As you say, some
> interpreters already come with a File object, but the whole point of
> standardising an API, to my mind, is to make sure you can write SSJS
> to one API and not many. If you're using ssjs.File then you *know*
> that it's the standard file object. If you're using File, then you
> don't know whether it's the SSJS file object or the interpreter's file
> object. Worse, if we override an existing global File with our global
> File then anyone who *wants* to make their project
> interpreter-dependent is out of luck, because we've overridden the
> interpreter's API.
>> 4) If you force all 3rd party libraries loaded through the package
>> system to also be part of this "ssjs" namespace, you're not fixing the
>> collision problem, you're just moving it down one layer.
> I don't think that's a good idea (it's certainly not what I'm
> proposing). SSJS would be the anointed, simple, API that does the
> basics. Other libraries can depend on it if they want to, but I don't
> think that they're part of it.
I think the concept of wrapping a bunch of existing incompatible APIs
in a library is a necessary evil of the browser world, which we should
try to avoid on the server, because we can.
Many of the things we're planning on doing will require modifying the
command line shells themselves. In the process I don't have any qualms
about replacing an old File object API with the new standard one.
But now that I think about it, none of the standard shells actually
come with a File object. So neither of our arguments on that one are
valid ;)
- Rhino has java.io.File, of course. No namespace conflict there though.
- SpiderMonkey/TraceMonkey has one that's not included in normal
distributions, and they don't sound very enthusiastic about it: https://developer.mozilla.org/En/SpiderMonkey/File_object - V8 doesn't have one (lv8call and v8cgi implement incompatible ones)
- JavaScriptCore doesn't have one.
Those are the "big four" in my mind. What others are there that we
want to support?
-tom
On Jan 30, 2009, at 3:48 AM, Stuart Langridge wrote:
>> 2) It's essentially what Ruby, Python, and many other languages do.
>> You usually don't see things like "Ruby.File.open()".
>> 3) Some command line JS interpreters already come with a File object,
>> but they all vary slightly in how they work. Hopefully this project
>> will standardize them, not augment them. Having "File" and
>> "ssjs.File"
>> is just confusing.
> I don't agree there. Python does that because there's only one Python
> interpreter. (Well, there are others, but they're explicitly
> compatible with CPython.) We have multiple incompatible interpreters.
> If there's going to be a global File object then we either wait for
> all the interpreters to implement it, or we implement it ourselves as
> a wrapper on top of whichever interpreter you're on. As you say, some
> interpreters already come with a File object, but the whole point of
> standardising an API, to my mind, is to make sure you can write SSJS
> to one API and not many. If you're using ssjs.File then you *know*
> that it's the standard file object. If you're using File, then you
> don't know whether it's the SSJS file object or the interpreter's file
> object. Worse, if we override an existing global File with our global
> File then anyone who *wants* to make their project
> interpreter-dependent is out of luck, because we've overridden the
> interpreter's API.
>> 4) If you force all 3rd party libraries loaded through the package
>> system to also be part of this "ssjs" namespace, you're not fixing
>> the
>> collision problem, you're just moving it down one layer.
> I don't think that's a good idea (it's certainly not what I'm
> proposing). SSJS would be the anointed, simple, API that does the
> basics. Other libraries can depend on it if they want to, but I don't
> think that they're part of it.
>> 3) Some command line JS interpreters already come with a File object, >> but they all vary slightly in how they work. Hopefully this project >> will standardize them, not augment them. Having "File" and >> "ssjs.File" >> is just confusing.
> I don't agree there. Python does that because there's only one Python > interpreter. (Well, there are others, but they're explicitly > compatible with CPython.) We have multiple incompatible interpreters. > If there's going to be a global File object then we either wait for > all the interpreters to implement it, or we implement it ourselves as > a wrapper on top of whichever interpreter you're on. As you say, some > interpreters already come with a File object, but the whole point of > standardising an API, to my mind, is to make sure you can write SSJS > to one API and not many. If you're using ssjs.File then you *know* > that it's the standard file object. If you're using File, then you > don't know whether it's the SSJS file object or the interpreter's file > object. Worse, if we override an existing global File with our global > File then anyone who *wants* to make their project > interpreter-dependent is out of luck, because we've overridden the > interpreter's API.
Your argument relies entirely on clashes with identically named objects in existing interpreters. I agree that that can be a problem — if, say, you redefine File.open() then anything that already relies on it in that implementation might break — but disagree that stuffing everything into a subnamespace is necessarily the solution: we can simply pick names that don't clash with the implementations that we're targeting.
My two cents: JavaScript already comes with the concept of global-level "class" names (Object, Array, Date, ..) and people (we!) are well used to this. The whole "encapsulate-or-die" stuff is the result of mixing client libraries, something we want (and can) evade.
So, I strongly opt for [global].File() instead of ssjs.File().
I think you're aiming too high by trying to get people agree on
namespaces at this time. IMO, what we should do now is talk about what
basic API should be provided - what classes and objects are available,
and what they do. I think namespaces are the last thing we need to
worry about, and in JavaScript it's just one line to turn a foo.File
into a File.
With Helma NG, you have full control how you want to access your
modules. import('helma.file') will put the module into a helma.file
namespace, while include('helma.file') will set up the File
constructor (generally all exported symbols) directly in your local
scope, and you can do var file = require('helma.file') to take control
of the namespace yourself. I personally wouldn't want to live without
this, just like no Python person in one's right mind would trade
python's module system for something less flexible.
Talking about File APIs, the helma.file module is built on top of
java.io.File:
http://github.com/hns/helma-ng/blob/89a30cf8b6f83e8f180a6d87d45d30f57... It has a few nice extras, like recursive copying of directories and
iterating through the lines of a file. For example, the following line
prints all lines of file README.txt prefixed with '>':
helma> include('helma.file');
helma> for (var line in new File('README.txt')) print(line);
I think it's things like this that are worth being considered as
standards or pseudo-standards.
Hannes
On Jan 30, 12:48 pm, Stuart Langridge <s...@kryogenix.org> wrote:
> > 2) It's essentially what Ruby, Python, and many other languages do.
> > You usually don't see things like "Ruby.File.open()".
> > 3) Some command line JS interpreters already come with a File object,
> > but they all vary slightly in how they work. Hopefully this project
> > will standardize them, not augment them. Having "File" and "ssjs.File"
> > is just confusing.
> I don't agree there. Python does that because there's only one Python
> interpreter. (Well, there are others, but they're explicitly
> compatible with CPython.) We have multiple incompatible interpreters.
> If there's going to be a global File object then we either wait for
> all the interpreters to implement it, or we implement it ourselves as
> a wrapper on top of whichever interpreter you're on. As you say, some
> interpreters already come with a File object, but the whole point of
> standardising an API, to my mind, is to make sure you can write SSJS
> to one API and not many. If you're using ssjs.File then you *know*
> that it's the standard file object. If you're using File, then you
> don't know whether it's the SSJS file object or the interpreter's file
> object. Worse, if we override an existing global File with our global
> File then anyone who *wants* to make their project
> interpreter-dependent is out of luck, because we've overridden the
> interpreter's API.
> > 4) If you force all 3rd party libraries loaded through the package
> > system to also be part of this "ssjs" namespace, you're not fixing the
> > collision problem, you're just moving it down one layer.
> I don't think that's a good idea (it's certainly not what I'm
> proposing). SSJS would be the anointed, simple, API that does the
> basics. Other libraries can depend on it if they want to, but I don't
> think that they're part of it.
On Jan 30, 8:18 am, Ondrej Zara <ondrej.z...@gmail.com> wrote:
> My two cents: JavaScript already comes with the concept of
> global-level "class" names (Object, Array, Date, ..) and people (we!)
> are well used to this. The whole "encapsulate-or-die" stuff is the
> result of mixing client libraries, something we want (and can) evade.
> So, I strongly opt for [global].File() instead of ssjs.File().
Shoving everything into the global namespace doesn't scale well,
especially when it comes to users wanting to build their own libraries/
frameworks. This was the story in Smalltalk, back in the day. We use
to have to prefix all our classes with product specific strings to
keep some amount of order (AbtXxxYyy, anyone?). PHP, today, does the
same thing, see the Zend framework for their naming scheme:
If you have to end up with prefixes anyway, they might as well be
first-class objects (in the "ssjs" sense) as opposed to prepended
strings in your function/class names. Objects == good.
As I hope some of the good stuff coming out of this effort might rub-
off on our JavaScript environments in browsers, I'm not terribly keen
on "ssjs" as the prefix though. "js"? "std"?
> I think you're aiming too high by trying to get people agree on
> namespaces at this time. IMO, what we should do now is talk about what
> basic API should be provided - what classes and objects are available,
> and what they do. I think namespaces are the last thing we need to
> worry about, and in JavaScript it's just one line to turn a foo.File
> into a File.
> With Helma NG, you have full control how you want to access your
> modules. import('helma.file') will put the module into a helma.file
> namespace, while include('helma.file') will set up the File
> constructor (generally all exported symbols) directly in your local
> scope, and you can do var file = require('helma.file') to take control
> of the namespace yourself. I personally wouldn't want to live without
> this, just like no Python person in one's right mind would trade
> python's module system for something less flexible.
> Talking about File APIs, the helma.file module is built on top of
> java.io.File:
> helma> include('helma.file');
> helma> for (var line in new File('README.txt')) print(line);
> I think it's things like this that are worth being considered as
> standards or pseudo-standards.
> Hannes
> On Jan 30, 12:48 pm, Stuart Langridge <s...@kryogenix.org> wrote:
> > > 2) It's essentially what Ruby, Python, and many other languages do.
> > > You usually don't see things like "Ruby.File.open()".
> > > 3) Some command line JS interpreters already come with a File object,
> > > but they all vary slightly in how they work. Hopefully this project
> > > will standardize them, not augment them. Having "File" and "ssjs.File"
> > > is just confusing.
> > I don't agree there. Python does that because there's only one Python
> > interpreter. (Well, there are others, but they're explicitly
> > compatible with CPython.) We have multiple incompatible interpreters.
> > If there's going to be a global File object then we either wait for
> > all the interpreters to implement it, or we implement it ourselves as
> > a wrapper on top of whichever interpreter you're on. As you say, some
> > interpreters already come with a File object, but the whole point of
> > standardising an API, to my mind, is to make sure you can write SSJS
> > to one API and not many. If you're using ssjs.File then you *know*
> > that it's the standard file object. If you're using File, then you
> > don't know whether it's the SSJS file object or the interpreter's file
> > object. Worse, if we override an existing global File with our global
> > File then anyone who *wants* to make their project
> > interpreter-dependent is out of luck, because we've overridden the
> > interpreter's API.
> > > 4) If you force all 3rd party libraries loaded through the package
> > > system to also be part of this "ssjs" namespace, you're not fixing the
> > > collision problem, you're just moving it down one layer.
> > I don't think that's a good idea (it's certainly not what I'm
> > proposing). SSJS would be the anointed, simple, API that does the
> > basics. Other libraries can depend on it if they want to, but I don't
> > think that they're part of it.
On Jan 30, 7:11 am, Thomas Robinson <tlrobin...@gmail.com> wrote:
> - Rhino has java.io.File, of course. No namespace conflict there though.
> - SpiderMonkey/TraceMonkey has one that's not included in normal
> distributions, and they don't sound very enthusiastic about it:https://developer.mozilla.org/En/SpiderMonkey/File_object > - V8 doesn't have one (lv8call and v8cgi implement incompatible ones)
> - JavaScriptCore doesn't have one.
> Those are the "big four" in my mind. What others are there that we
> want to support?
For environments that don't include a *real* file API, it's easy to
build a layer on top of the ActiveXObject access. That's what I've
been doing internally for a while, and it will be nice to have an
*official* file API to follow rather than taking random inspiration
from different sources.
> Shoving everything into the global namespace doesn't scale well, > especially when it comes to users wanting to build their own > libraries/ > frameworks.
Those are two separate issues. The standard stuff defines a (limited) number of objects in the global namespace (e.g. File) and then extensions do whatever they want, except that good practice is documented telling people not to pollute the global namespace. That's how CPAN works, and overall it works really well.
On Fri, Jan 30, 2009 at 5:11 AM, Thomas Robinson <tlrobin...@gmail.com> wrote:
> I think the concept of wrapping a bunch of existing incompatible APIs > in a library is a necessary evil of the browser world, which we should > try to avoid on the server, because we can.
Since this group is essentially a specification group, that is just a matter of specifying only one API.
> Many of the things we're planning on doing will require modifying the > command line shells themselves. In the process I don't have any qualms > about replacing an old File object API with the new standard one.
> But now that I think about it, none of the standard shells actually > come with a File object. So neither of our arguments on that one are > valid ;)
Command shells are applications (just like browsers are) where the application has a JavaScript interpreter embedded inside the application.
> - Rhino has java.io.File, of course. No namespace conflict there though. > - SpiderMonkey/TraceMonkey has one that's not included in normal > distributions, and they don't sound very enthusiastic about it: https://developer.mozilla.org/En/SpiderMonkey/File_object > - V8 doesn't have one (lv8call and v8cgi implement incompatible ones) > - JavaScriptCore doesn't have one.
It is the host application's job to expose access to things appropriate to the particular scripting environment. A server-side interpreter can expose a File object. A browser interpreter should not. So it is good that SpiderMonkey and V8 don't expose File as a standard host object.
> Those are the "big four" in my mind. What others are there that we > want to support?
This discussion group won't support JavaScript implementations. Host applications will choose to support the results of this discussion group by adding host objects and only if a particular host application finds doing so worthwhile and beneficial.
On Fri, Jan 30, 2009 at 6:52 AM, Robin Berjon <robin.ber...@gmail.com> wrote:
> On Jan 30, 2009, at 14:53 , pmuellr wrote: >> Shoving everything into the global namespace doesn't scale well, >> especially when it comes to users wanting to build their own >> libraries/ >> frameworks.
> Those are two separate issues. The standard stuff defines a (limited) > number of objects in the global namespace (e.g. File) and then > extensions
Although a standard File API would be great, the actual File implementation can be as an extension itself. The only thing that needs to be added to the JavaScript interpreter is something like "load" to execute other files of code. One of those files of code could contain a File object.
> do whatever they want, except that good practice is > documented telling people not to pollute the global namespace. That's > how CPAN works, and overall it works really well.
I agree. A library author should not be forced into a straight jacket. He should be shown how to put on the straight jacket himself. I think most JavaScript programmers realize a library global function called "trim" has a good chance of namespace collision and would like to avoid that.
import("File")
Import the standard File object directly into the global namespace. So
now you can do
var f = new File("some.txt");
var lines = f.readLines();
or
var lines = File.readLines("some.txt");
Maybe import could have an optional second argument, which object to
insert into:
var myObj = {};
import("File", myObj)
var f = new myObj.File("some.txt");
var lines = f.readLines();
or
var lines = myObj.File.readLines("some.txt");
This way those that are ok with polluting the global namespace for
efficiency sake can just import away.
Those that want things all in a single object like SSJS or something
can do that.
The question then becomes where does import live?
Does it sit in the global object, do we have a tiny few number of
these?
Maybe a command line switch to optionally have import and other
similar functions be put into a new SSJS object in global rather than
directly in global. Again, giving pollution control to those that want
it.
It's trivial to implement both (well it is for v8 and for
spidermonkey, dunno on the other interpreters) and seems ok to me to
implement both.
On Jan 30, 9:52 am, Robin Berjon <robin.ber...@gmail.com> wrote:
> > Shoving everything into the global namespace doesn't scale well,
> > especially when it comes to users wanting to build their own
> > libraries/
> > frameworks.
> Those are two separate issues. The standard stuff defines a (limited)
> number of objects in the global namespace (e.g. File) and then
> extensions do whatever they want, except that good practice is
> documented telling people not to pollute the global namespace. That's
> how CPAN works, and overall it works really well.
On Fri, Jan 30, 2009 at 5:18 AM, Ondrej Zara <ondrej.z...@gmail.com> wrote:
> My two cents: JavaScript already comes with the concept of > global-level "class" names (Object, Array, Date, ..) and people (we!) > are well used to this. The whole "encapsulate-or-die" stuff is the > result of mixing client libraries, something we want (and can) evade.
> So, I strongly opt for [global].File() instead of ssjs.File().
I mostly agree and would like to agree completely.
I think that CPAN offers a good example to follow. Because CPAN is the canonical repository, code in CPAN can define a global like "File". The CPAN maintainers approve new namespaces to avoid collision. If everyone else in the Perl world uses a prefix containing who they are then that will never collide with CPAN naming because CPAN naming doesn't contain any information about who is writing the code. So a company called XYZ would write an XYZ::File module and that would likely never collide with any CPAN module because "XYZ" is a company name and likely not appropriate for a CPAN module. There is still some risk.
Java takes this to what might be considered an extreme by using reverse domain names. That same company's class would be com.xyz.File and this naming convention almost ensures no collisions as domains are registered with a central service.
For a standardized JavaScript file object, if the desired semantics are a global file object then it is a matter of choosing a string for that object's identifier. Choosing "File" would work. Choosing "std_File" would work. Even "asdf" would work. Some of these are better than others but they all have the same semantics.
> On Fri, Jan 30, 2009 at 5:11 AM, Thomas Robinson > <tlrobin...@gmail.com> wrote:
>> I think the concept of wrapping a bunch of existing incompatible APIs >> in a library is a necessary evil of the browser world, which we >> should >> try to avoid on the server, because we can.
> Since this group is essentially a specification group, that is just a > matter of specifying only one API.
>> Many of the things we're planning on doing will require modifying the >> command line shells themselves. In the process I don't have any >> qualms >> about replacing an old File object API with the new standard one.
>> But now that I think about it, none of the standard shells actually >> come with a File object. So neither of our arguments on that one are >> valid ;)
> Command shells are applications (just like browsers are) where the > application has a JavaScript interpreter embedded inside the > application.
Yes, but the interpreter doesn't implement the File object, otherwise we would all have File objects in the browser. The shell, or some library included by the shell, implements it.
>> - Rhino has java.io.File, of course. No namespace conflict there >> though. >> - SpiderMonkey/TraceMonkey has one that's not included in normal >> distributions, and they don't sound very enthusiastic about it: https://developer.mozilla.org/En/SpiderMonkey/File_object >> - V8 doesn't have one (lv8call and v8cgi implement incompatible ones) >> - JavaScriptCore doesn't have one.
> It is the host application's job to expose access to things > appropriate to the particular scripting environment. A server-side > interpreter can expose a File object. A browser interpreter should > not. So it is good that SpiderMonkey and V8 don't expose File as a > standard host object.
>> Those are the "big four" in my mind. What others are there that we >> want to support?
> This discussion group won't support JavaScript implementations. Host > applications will choose to support the results of this discussion > group by adding host objects and only if a particular host application > finds doing so worthwhile and beneficial.
That's ideally how it would work, but I suspect if we just release a spec and hope for the JS engine developers to implement it themselves it will take years. I think we'll need to actively develop at least one "reference implementation" of the spec.
But if there are JS engine contributors here who plan to support this project, it would be nice to hear that :)
I saw Norris Boyd (creator of Rhino) is on the list, but I don't know if he or anyone from the Rhino project plans to actively implement this stuff.
