Comments on: Modules: Allow Module Overloading?

Modules bring up many new issues. Here is a new one for REBOL experts to consider:

Should programs be allowed to overload a module? That is, is it valid to load a module twice?

Concepts to remember when thinking about this question:

• Modules are identified by name (a word)
• Modules create their own context (namespace)
• Modules have version numbers
• Modules can be explicity loaded
• Modules can add exported values to the global environment

So, what advantage is there in allowing overload: It lets you overload exported functions of a module. For example, if some of your program requires an older version of a module, but other parts require a newer version.

This can become a complex issue, and we really like to keep complexity out of REBOL. If we can specify a few simple rules, programmers of all skill levels will benefit.

13 Comments

Comments:

Pier Johnson 12-Oct-2006 20:23:54	There will be those in the camp that shouts "YES" in favor of overloading modules. Those of the 'YES' camp will call for this simply because they're stuck in a paradigm of academic computing. When one requires results from a Legacy REBOL based script (REBOL v2.n), simply run Legacy REBOL in one process and fetch results using REBOL/Services using a script running on State-of-the-Art REBOL (REBOL/3). Has all lost focus of the purpose of REBOL -- inter-computing communication? It's far easier to have REBOL-to-REBOL talk through services than it is to muck up REBOL with already tried-and-failed shackles from High Priests of Computing Academia. Adding the kitchen-sink to REBOL will make REBOL junk, just like Python, Ruby, Perl, Java, C++, C#. Way too many ineffective languages exist, but so few tools exist that generate results. Product developing without considering customers and markets is just folly. Here's some good stuff you can read -- golden rules of product developing at Pier 23 For whom are you making REBOL? CIOs sysops the everyday person capable of doing great acts with browser/google search, email and IM messaging, Lotus 123/Excel formulas, old days dBase scripts twiddling thumb "don't know what ROI is" academics and their minions Each day that passes without REBOL/3 and a focused market-oriented purpose for REBOL/3 is another day that contributes to decline, disappearance, death of an otherwise what-could-be brilliant product.
Ladislav 12-Oct-2006 20:59:21	I am not sure whether I would need module overloading, but in addition to: "It lets you overload exported functions of a module. For example, if some of your program requires an older version of a module, but other parts require a newer version." I can imagine another advantage. Let's suppose we have got a truly long-running REBOL server (months) using a module, which has been recently updated by its creator. Wouldn't it be nice, if the server were able to overload the module instead of us being "forced to" restart the server to use the updated module?
Maxim Olivier-Adlhoch 12-Oct-2006 22:26:17	if a module does not handle itself by its header... could it then be a little bit more dynamic and make overloading a moot point? I mean, instead of specing what is imported, what is exported, and any other feature, in the header... why not supply an internal callback which can be called on the fly, by the module's parent context? also, if/since? a module is assigned to a word, if using the module trough module methods (my-module/method args), then it will also adapt transparently. reloading a module is VERY usefull in many cases, especially when they can be concurrent. it allows things like sessions to be coded ultra secure. it might allow multiple instances of a plugin to be loaded for independent streams of computing... imagine having two mp3 players running from the same rebol task (since it will be multi-threaded), to do live mixing, without having to do any complex DSP or mixing algorythms. And as ladislav points out updating code which is live, is very usefull too. just like I redo code when I detect file date change! Allowing me to fix my server without having to restart it... I hope I make sense!? I stopped tracking the previous thread... it was getting a bit too close to theroretical astrophisics ;-)
Oldes 13-Oct-2006 5:16:23	I would like possibility to overload module and especially UNLOAD module just for the case which described Ladislav - the server scenario.
Oldes 13-Oct-2006 5:24:08	But I'm not sure how should it be secured and it must be secured as I would not like to have some script to unload/overload module which I need for another script. It looks, that we should more and more think about Rebol like about an operating system, not just like about simple script interpreter for text manipulations. What about to add passwords to the module concept?
Oldes 13-Oct-2006 5:36:10	Now when I'm reading again the previous thread, the passwords are already in the concept: Carl: If a module has been signed, a valid equivalent signature may be required for patching it. Of course, you can also use SECURE NONE style method. Maybe it should be added to the list above.
Brian Hawley 13-Oct-2006 10:06:13	Pier, just because someone in academia came up with an idea doesn't make it a failed experiment. Many of the experiments of academia succeed and become part of the basic infrastructure of our technical world. The problems that arise when having to support code over time are pervasive, and has been the subject of much research by academia and others. Some of that research has come up with some good ideas that work. Remember, REBOL isn't about being different for the sake of being different - it's about being different for good reasons and only when it matters. Every way that REBOL is different from other tools has a rationale behind it, even the syntax differences. You shouldn't dismiss good ideas out of hand just because they were developed by people you don't like. Genuine insight has come out of research done by academia, the military, the porn industry, hackers. Evaluate any ideas based on their own merits.
Brian Hawley 13-Oct-2006 10:26:07	Perhaps it would be a good idea to refer to modules by both their name and version. I think it is a bad idea to have modules just assigned to global variables when they are loaded. If you just put script modules in global variables it can lead to stability and security holes that I have demonstrated earlier. It's better to keep the script module namespace seperate, and consider dynamic modules to be anonymous until interred. It may be a good idea to think of importing a module as a process, perhaps static through module headers or dynamic through a native function. That header or function could take parameters that would let you specify whatever you would need to get to the right module, be it just the name (at which time you would get the latest version available), or a name and some version constraints. Or the function could take a module value that was dynamically created and import from that. This would give us the kind of flexibility we need when we need it, and let us ignore the options and behave sensibly by default when we don't care about the versions.
Robert 14-Oct-2006 4:25:19	I just want to throw in some idea to think about in this context: 1. Namespace: Can I specify the namespace the module uses? Maybe my app just want to use the module with an other base name. 2. Versioning: How about adding something like a path notation. my-module/v1/set-name my-module/v2/set-name As we have namespaces anyway, this could be mapped internaly. 3. Being able to LOAD/UNLOAD at runtime is, as Ladislav stated, a big advantage for long running and always-on applications. The trend for such apps is there. So IMO it makes sense as long as it's simple and clear to understand.
Jerry Tsai 14-Oct-2006 4:56:15	In .NET, an assembly refers to another assembly by it's "strong name," which including name, version, locale (culture), and public key (the assembly maker).
Brian Hawley 14-Oct-2006 10:09:29	I think modules are namespaces Robert, but that brings up an interesting idea: Can we have the option of importing a module as just the module name, perhaps a name we specify, instead of importing its exported words directly into the current environment? Then we can access the module's exported words using paths off the module. Perhaps a way to retrieve a module value (based on its name, version, ...) and assign it to a local word.
Darkblue 24-Oct-2006 4:01:05	the possibility to overload a module could be managed by the secure function! Basically the module overload is not allowed but you can specify in the secure block modules which can be or all modules
Maxim Olivier-Adlhoch 2-Nov-2006 12:50:08	Brian: That is how slim functions and its very usefull. I hope that this will still be possible with R3 modules. it allows users the power to decide how its namespace is polluted. it also give the module author a means to decide what can be exported, so both sides have control on their part of the equation.

Post a Comment:

You can post a comment here. Keep it on-topic.