The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 |
From: Kris Kowal <cowbertvon...@gmail.com>
Date: Thu, 28 May 2009 09:45:06 -0700
Local: Thurs, May 28 2009 12:45 pm
Subject: Re: [serverjs] Re: RFC reqiure.paths behaviour
On Thu, May 28, 2009 at 1:24 AM, Hannes Wallnoefer <hann...@gmail.com> wrote: Alright, module.path. > I actually like "path" and think "file" and "fileName" have their own > problem of hinting to the pure file name. >>> And I'm not quite sure how to build up a ID I think that it's okay to use the absolute path as the id for scripts, >>> for a module that isn't in the search path. Say i have: >>> my_serverjs_interpreter /opt/my_app/my_app.js > This is why I think it would be better if require.main contained the > program path. I think it is safer to assume that the main program has > a path than a module id, and checking if a module is the main program > would still be simple: as long as absolute paths are not used as ids within modules. When possible, it would be better to reconstruct the id of a module within the search path, but I haven't done so yet, and I understand that it's onerous. It would be troublesome for the require.main to be the path though for modules that do not have paths. Also, while Ash Berlin's idea of using a URI has merit, I would like to leave open the possibility of a later standard that extends the module identifier domain to include URL's. Doing so right now would leave too many open variables and more discussion than is necessary in the short term. > if (require.main == module.path) { ... } I agree to the extent that for practical purposes (beyond the > Admitted, this introduces the risk of getting confused by specification) that absolute paths are an acceptable strict-superset of module identifiers, and that URI's would be an acceptable strict-superset thereof when need arises and the time comes for carving out that namespace in excruciating detail. > In Helma NG, the directory containing the main script is added to the Python does something similar, and I think that it causes problems in > front of the module search path by default, and the modules directory > in the helma-ng home directory to the end. Thus, applications > consisting of a single app directory can be run without worrying about > the module search path. You only have to set the module search path if > your application consists of several script repositories, or you're > using libraries that aren't installed in helma-ng's modules directory. > I think this is working pretty well for us. the very long term. I'd recommend that scripts use relative id's to refer to neighboring resources instead of top-level id's. Otherwise you run into the problem where your application's name space may mask a module on the top-level identifier space. For example, if your application has an "file" module, the standard library's "file" module would become inaccessible. Kris Kowal You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
| |||||||||||||