@Raul Re-reading this thread I think my terse reply could be taken for curt. I apologise if this has given offence.
Let me re-engage with your reply, this time more carefully. * * * * * My question had two parts. Paraphrasing them: 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. 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". A "load" with mode qualifiers is one thing. But "require" would be expected to offer identical facilities... and then what? Verb "require" is fine for calling at the point of use (of the required verb), because it entails negligible overhead to check if the script has been loaded already. What "require" can't do -- and shouldn't be asked to do -- is to check if the resulting addon code is in a fit state to support the task envisaged. More precisely: is it in the mode specified? I was aware of this, so I put in a "Sundry question" -- which I answered as follows. Verb "require" should be a no-op if the addon script has been loaded. If it's in a different mode from the one asked-for, then too bad. This problem exists already with "require": an addon may create cached data, so "require" cannot undertake to recover its state when freshly loaded. Nor, for that matter, can "load". If however the addon needs loading, then -- hey! -- we now have a facility to ask for it in a "lite" version (say), or maybe with our default choice of terse/verbose, trace/notrace, unicode/ascii --or any of the legion of options which I as the developer see a need for. I frequently want to know of the user: is the "lite" code going to be good enough for you, or is your usage so demanding you need the slower, more fastidious, code? But in that case, why should "require" accept mode qualifiers at all, if (once loaded) they're apt to be ignored? Purely for compatibility with "load"? Might there be a call in the future for the mode flag to be treated as a level number (and so stored separately for each addon) to be checked by "require" to see if the script needs to be reloaded at a higher level? When I think of how to implement *that* I get a dull pain between the eyes. Goodbye "negligible overhead", for a start. I haven't got a good answer to all of this. I was happy to ignore the problem, because it didn't matter for the addons I have in mind. But on second thoughts it's like a piece of wool hanging from your jumper which, when you pull it, unravels the whole garment. 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. Ian On Thu, Sep 6, 2012 at 5:43 PM, Ian Clark <[email protected]> wrote: > No I'm not sure I can't solve it some other way. That's why I'm asking. > >> Why? > > Why shouldn't I want an addon that can be loaded in different modes? > (Forget about "require" for now.) > > On Thu, Sep 6, 2012 at 5:10 PM, Raul Miller <[email protected]> wrote: >> On Thu, Sep 6, 2012 at 11:00 AM, Ian Clark <[email protected]> wrote: >>> Say I want to release an addon called: misc/zulu. It has a choice of >>> modes to load it in. >> >> Why? >> >> The require mechanism assumes that once something is loaded that it >> does not have to be loaded again. >> >> It seems to me that offering load time options defeats this mechanism. >> >> So... what problem are you trying to solve? And, are you sure you >> can't solve it some other way? >> >> Thanks, >> >> -- >> 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
