| [#962] | project: interpreter | priority: low | category: missing feature | |
|---|---|---|---|---|
| submitter | assigned to | status | date submitted | |
| Nikolay | Lex | open | 2007-02-23 15:23:58.0 | |
| subject | [contrib #347] default load-directory | |||
| code |
This is related to feature request, bug #929. If one could set the default directory for :load, dealing with multiple files would be fast. :setdir "long-path" :load "now.scala" => loads "long-path"+"/"+"now.scala" If you compare this to #929, one could get the same effect by using: val base = "long-path/" val work = base + "now.scala" val another = base + "do.scala" The latter is more general, and much handier if there's many directories involved. But you could use both, or just default dir -solution in case the implementing time of the feature is important. |
|||
| what happened | ||||
| what expected | ||||
| [back to overview] | ||||
| Nikolay edited on 2007-02-23 15:24:23.0 |
| contribution #347 |
| Nikolay edited on 2007-02-23 15:31:26.0 |
|
In a personal email, Henrik Huttunen further specified
The default dir should be permanent between sessions. e.g. if the interpreter crashes, it's annoying to type the dir again and again, especially, when the path is quite a long. Implementation issue: should check that the default dir exists when scala is started and when :load is used (if the dir was removed). One would then get different message than "error opening file" which is for .scala files. |
| Lex edited on 2007-02-23 17:32:34.0 |
|
Making loading convenient requires thinking about how people can organize their script files.
As one quick thought, it would seem nice to have a load *path*. It would work just like a Java classpath or a shell PATH. One way would be to expose this as a var that is manipulated by interpreted code... Otherwise there would have to be : commands for setpath, addfront, addend, reset, append, and on and on, and there would be no good way to use strings as discussed in #929. Additionally, there should be a way to set these things in the environment, perhaps with Java properties and property files.... |