(Note to the moderator... I can't remember if this is a members-posts-only list... In which case I'll need to change my email address since I'm recieving this list via a redirection still in affect on a read-only and soon to be erased account)
> I have noticed that, sometimes (often?) hook serial numbers are > actually overkill when compared to what the user actually wants to do > with them. I think that, in a lot of cases, it is simply desirable to add > a hook which is not the default action and occurs sometime before or > after the default action is taken, and irrespective of order. Therefore > I would propose to extend the serial number interface to the /on > command to take simply a '+' or a '-' for the serial number and add > the action to a generic before/after list on the hook with unspecified > ordering. This would solve the problem of trying to use unique serial > numbers and avoid serial number collisions. There's a problem here, in terms of removing the /on binding later, if you don't know the serial number it was registered with. I actually implemented a combination of that and your latter namespaces proposal in a script I wrote some time back. I lost the script about a year or so ago, but basically it was a wrapper for /on, which accepted a "module name" (basically equivelant to your namespaces) in place of a serial number, with + or - prefix to alter the serial number. The script still accepted a serial number as per usual, but also accepted a name with optional prefix (+ / -). The "module name" was used to identify a collection of "allocated serial numbers", which were mirrored +ve and -ve, with the +/- prefix setting the sign of the serial number used (the serial numbers allocated were multiples of 10, and biased on the -ve side to preserve proper first-in-first-served order). Though the /on wrapper only used the names for the first serial number allocated to the "module" (I did have plans for a ".digit" or ".subname" qualifier), arbitrary serial numbers could be allocated as needed (the function returned the serial number which could be stashed in a variable), and the script could be asked to allocate a number above or below another allocated serial number. Actual module names were registered near the start of a script (like the package command, which was added to EPIC sometime later, and I actually called from the registermodule function). The registermodule function taking the scripts current major and minor version number, and a brief description. The function then returned a number from 0 to 2 indicating whether the module was already registered (2), registered at a lower version (1), or has just been registered for the first time this session (0). This allowed scripts to easily perform initialization just once, and preserved their existing load order, even when loaded several times. An extention to that, was demand loading with a "load module" command which first checked that the module wasn't already loaded (it would attempt to load if not, or reload if the optionally requested version criteria was not met). And like registermodule, it returned a value indicating that the script wasn't loaded (0), was loaded okay (2), or was loaded but still didn't meet the version criteria (1). I also overode the case where no serial was given at all, defaulting to the last module registered, with setting an event at serial 0 needing to be explicitly requested. As an extra, any functions registered at serial 0, were actually assigned to a function instead, and a wrapper put in place to implement what is now the ? mode /on's (before they were implemented), with the implementation of a "weak" serial-0 which is called if none of the other serial-0 hooks reply as handled. > I want to add a 'namespace' command which changes the current > namespace ..... more useful side effect, which is to allow different > pieces of script to declare aliases and assigns with the same name > without having collisions and confusion. I used to package every little assign under the name of the module, or a few common sections for configuration and what-not. A real pain in the butt, so this feature would have been most welcome. > 1) Check to see if symbol is fully qualified (contains ::) > 2) Check to see if symbol exists in the current namespace > 3) Check to see if symbol exists in any using namespaces > 4) Check to see if symbol exists in the global namespace > If the symbol comes up empty one of two actions is taken. If the > symbol is being acessed/defined in a non-global namespace it > becomes a member of that namespace, otherwise it becomes a > member of the global namespace. Sounds perfect to me. I'd like to see an option to the package command, simulating following it with a namespace command with the same name. Unless, of course, it is decided that packages will be placed inside a namespace. Which would be even better, though potentially destructive to existing scripts. > [3] I would also add a 'using' or 'use' command to add namespaces > into a list of namespaces to always search for symbol resolution. > That might be deemed unnecessary though, and in that case could > be left out. I think it's a very good idea, personally. You'd probably want to maintain first-in-first-searched order in the list to keep things more or less predicatable. Though it could none the less become confusing fairly easily. So a warning should probably be attached to the docco for the using/uses command advising people of the dangers. It might even be worth expanding bless to form permanent links between namespaces, making a variable (or branch) common to both. I'm not sure if you'd want to allow it to link in an entire namespace or not. A further application of the uses clause, would be to allow "read-only" access, allowing you to set up a "default values" namespace (similar name to the scripts main namespace), preloaded with said values, and then import it with uses into the normal namespace (may even want to automate the process with a special option to the namespace command). Reading values would come from the default namespace, while creation of new values would occure in our normal namespace. (You could still specify the namespace explicitly to change a "default" value) This is a feature I'd loved to have had when I wrote that modules script! _______________________________________________ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
