Comments on: WHAT on Modules

Carl Sassenrath, CTO
REBOL Technologies
2-Jul-2010 19:27 GMT

Article #0325
Main page || Index || Prior Article [0324] || Next Article [0326] || 5 Comments || Send feedback

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.



Brian Hawley
9-Jul-2010 16:45:11
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.
Carl Sassenrath
13-Jul-2010 19:11:25
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
m/set-resolution 1600x1200
draw drawing

All three are functions of my-graphics, but only DRAW is exported.

With this in mind, WHAT should show the other functions.

Brian Hawley
14-Jul-2010 1:03:12
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.

14-Jul-2010 2:51:15
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".
Brian Hawley
17-Jul-2010 3:38:03
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.


Blog id:



 Note: HTML tags allowed for: b i u li ol ul font span div a p br pre tt blockquote

This is a technical blog related to the above topic. We reserve the right to remove comments that are off-topic, irrelevant links, advertisements, spams, personal attacks, politics, religion, etc.

Updated 24-Mar-2017 - Edit - Copyright REBOL Technologies -