Comments on: WHAT on Modules
I've made a small change to WHAT to make it easy to see functions defined within a specific (named) modules.
For example, in the current graphics module (which is still be moved to the host-kit so only contains a few functions at this time):
>> what graphics
box Draw a rectangular box.
circle Draw a circle or ellipse.
do-events Waits for window events. Returns when all windows are closed.
fill-pen Set the area fill pen color.
handle-events Adds a handler to the view event system.
handled-events? Returns event handler object matching a given name.
init-graphics Initialize graphics subsystem.
init-view-system Initialize the View subsystem.
pen Set the line pen color.
show Display or update a graphical object or block of them.
unhandle-events Removes a handler from the view event system.
unview Closes a window view.
view Displays a window view.
Here's an example of the HTTP protocol module:
>> what http
do-request Perform an HTTP request
http-error Throw an error for the HTTP protocol
make-http-error Make an error for the HTTP protocol
make-http-request Create an HTTP request (returns string!)
This comes in handy.
We need to make sure that non-exported functions are not shown by default, or not shown by option. Modules have functions for internal use that are not exported. We don't want to imply that these functions are part of the interface of the module.|
It's interesting, because it depends on the definition of export. Currently, we define export essentially to be: add it to the system exports context. But, it is valid to write a module that has externally used but non-exported functions.
m: import 'my-graphics
All three are functions of my-graphics, but only DRAW is exported.
With this in mind, WHAT should show the other functions.
The point you made in AltME about what returning all exported functions by default, and all the available functions of a module when the module is specified is an interesting one. It would make what a good reminder that the purpose of the Exports field is not encapsulation, it is binding control. The non-exported words are still available for reference unless you hide them explicitly; they just aren't imported into the "global namespace", to the extent that R3 has such a thing.
This appears to be another occasion where we should apply the rule that if you want to hide something then you have to hide it, using protect/hide or other techniques. Simply not exporting is not hiding.
What is the purpose of 'export at all then? What is the difference in writing 'init-subsystem vs m/init-subsystem? Only the binding? How usefull is that? I thought that non-exported functions are going to be "protected" or let's say "hidden".|
The point of exports is to make the word be included into the global exports context - essentially importing the word into the system. That context is imported into all scripts and modules, for everyone to use. So the use of exports is system integration and code organization, not encapsulation. It's how you can write user script code in R3 without needing to specify included modules most of the time.
If you want to make things available but not set any global words, don't export the words, but don't hide them. Explicit access to modules can be useful for many purposes, but it's less useful to modularity newbies so it's not done that way by default.
We will have a separate hidden keyword for words that you really want hidden, though the facility to hide words already exists as protect/hide. You may find that these occasions are more rare than you might suppose; encapsulation is rarely needed by a disciplined programmer, and is mostly a cause of code bloat in many languages.
Post a Comment:
You can post a comment here. Keep it on-topic.