@Raul @Devon Yes, thank you both, your thoughts have helped me a lot.
Though I guess I knew most of that already. But what was bugging me was this one simple thing... My proposed addon 'misc/zulu' is meant for raw beginners. Consequently I want them to "require" it in as easy a way as possible. I've just been experimenting with one of my own addons: math/uu. The easiest way for me to offer different modes is to have a separate loader-script for each mode, all residing in the ~addons/math/uu/ folder. Turns out this is the easiest for the novice user to use and remember, too. And that's all down to something Raul tells me I didn't know: namely that (say) ... load 'math/uu/9' will successfully load a file called: jpath '~addons/math/uu/9.ijs' Ditto... load 'math/uu/trace' will successfully load a file called: jpath '~addons/math/uu/trace.ijs' ...and with that I'm home and dry. BTW counterintuitively (to me anyway), the following will *not* work (and I was well aware of it) ... load 'math/uu/9.ijs' not found: /Applications/j602/math/uu/9.ijs |file name error: script | 0!:0 y[4!:55<'y' ...It needs: load '~addons/math/uu/9.ijs' >>> mode script: 9.ijs --loaded ...But then *this* doesn't work: load '~addons/math/uu/9' not found: /Applications/j602/addons/math/uu/9 |file name error: script | 0!:0 y[4!:55<'y' ...That's going to be a minefield for the novice. It takes long experience to get familiar with all that. It was rough edges like this that made me yearn for a more robust form of "load/require" statement. This was the real burden of my elaborate query. Because I knew such things get up the nose of a novice, making them despair of ever being sure what they're doing. I contemplated a fix to getscripts_j_ so that... >getscripts_j_ 'math/uu9' ...would return: /Applications/j602/math/uu/uu9 ...instead of: /Applications/j602/math/uu9/uu9 This would help a lot, I thought. But then while playing about with all this, it occurred to me I could make it simpler still... I could contrive to insert entries into PUBLIC_j_ ...which is built, I think, by: jpath '~system/extras/config/scripts.ijs' ...A simple change to the base package, of an uncontentious nature, I trust. Then I could offer a choice of: require 'zulu' require 'zulu1' require 'zulu2' ... require 'zulu9' What could be simpler? Well, now I've mulled it over for half a day, that's the way to go, I guess. Ian On Thu, Sep 6, 2012 at 9:54 PM, Raul Miller <[email protected]> wrote: > On Thu, Sep 6, 2012 at 3:39 PM, Ian Clark <[email protected]> wrote: >> Re-reading this thread I think my terse reply could be taken for curt. >> I apologise if this has given offence. > > No offense taken. > > Disorientation on the other hand? I have been taking some of that... > >> 1. Is there a recommended way of doing this, viz offerring and >> specifying a load with a mode qualifier? >> >> 2. Is there a need for such a facility? In what form? >> >> From your reply I can infer the answer to 1. is No. Because otherwise >> you would have pointed me at it. > > This is not strictly the case. However, It Is Not That Simple (and > maybe I want to keep my disorientation to myself...) > >> On the other hand there might indeed be a recommendation, which is >> Don't Do It. And Don't Even Think Of It, because it risks causing a >> lot of trouble for the implementation of "require". > > For some cases of "load differently", yes, this is the probably the > case. Specifically, if there are significant differences which are > visible after the load, I would advise against "modal loading". > > However, for other cases of "load differently", it might be no big > deal. Specifically, if you only notice the differences while the > files are being loaded (for example: optional diagnostics being > emitted to the session, describing the progress of the load), then > this could be a reasonable thing. > > ... > >> I do need a way of loading different combinations of scripts when my >> proposed addon 'misc/zulu' is first loaded. If there's no recommended >> way of doing this then I'll cobble up my own. But It would be nice if >> the different "load" options were (almost) as easy to specify as a >> simple "load misc/zulu" . I would expect the user of "require" to >> accept the addon in whatever mode it has been loaded, and to >> understand that any mode qualifier only applies on first loading. > > If your requirement is to actually load different contents, then I > would present this as different files to be loaded (or required). > > In other words: > > require 'misc/zulu/normal' > > NB. or > > require 'misc/zulo/trace' > > Note also that the "trace" file(s) could require the "normal" file(s), > if that helps you. (But why would you not want to be able to switch > trace on and off after the load?) > > If your requirement is to give optional diagnostics on the loading > process then I would check for the existence of a control variable in > a locale which is "owned" by your loading process. > > In other word: > > load 'misc/zulu' [ TRACE_zulu_=: 1 > > Your implementation might then look something like this: > > cocurrent 'zulu' NB. or coclass... > ... > 3 :0'' > if. 0 = nc <'TRACE' then. > NB. debug stuff goes here > end. > ) > > Here, a bare load would get normal behavior. Defining the name with a > noun would get the debug behavior. If you like you could forcibly > turn the load tracing behavior off, after possibly previously enabling > it: > > load 'misc/zulu' [ erase 'TRACE_zulu_' > > I hope this helps, > > -- > Raul > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
