Comments on: What's an extension?
There's been some discussion and perhaps a bit of confusion about REBOL extensions (previously called plugins.)
Well, first let me mention that the official definition of REBOL Extensions is now published. (And, if you think you can help improve it, go ahead, it's a wiki, or at least relay your ideas on R3 Chat group #5045).
Here's a clarification that should help:
| ||a module||is written in REBOL only and defines code and data (any data, including images, sounds, tables, mini-databases, etc.) Its functions and other values can be exported to your programs or kept isolated within the module context itself. Complete details are published in the REBOL Modules section of the new R3 documentation.
| ||an extension||is a module that also allows native code and data. So, it includes a module definition, just like that above, but it can also create commands that are similar in performance to REBOL native functions. It can also store data, export values, keep isolated values, etc.
A user asks, "Can I package all my special data into a module or extension? I don't want to scatter it around in separate files." The answer is yes, you can. Just include it in your module or extension as you would any other data.
If that question was meant to be: "Is there a tool for making that inclusion automatic?" My answer would be that such a "helper" script is quite useful, and I'm sure that one or more persons in the R3 community can provide it quite soon.
Fine to forget the "plug-ins" as useable terms.
But as I understand the descriptions:
What now is called an "extension" seems to be a C-interface.
What now is called a "module" is just an additional way to implement user-functions.
Wouldn't it even be better to abolish these, sorry, cryptic distinctions between "extensions" and "modules", too?
Why not name those things according to the topics they refer to? - And btw save time and double documentation as we see in the modules chapter? ;-)
Sorry, system didnt accept my two links:
Here is the first one:
...and here the second:
According to REBOLs well known and accepted philosophy simple things should be kept simple.
But we see a growing lot of different ways to implement user-functions.
"Function, funct, funco, func, has, does, modules, extensions..." - Don't know if there are even more.
At least for new users this is much complexity for a very basic issue! - Is it really needed?
Generally I think the standard concept should be
1. that no function name may conflict with native function names,
2. that all variables used in functions are just local (not public - and not static or private as they still seem to be in all cases except (maybe I'm wrong) the C-interface, called "extension".
3. that parameters passed in REBOL by reference (arrays, series, blocks, strings..) must be protected by users themselfs if they really want and need that. Its normally a good idea, to pass those possibly very large strings, arrays etc. by reference, as REBOL does. Protections can only be judged by the user himself and be set using copy/deep.
Just one of the above mentioned function calls - at best what is now called a "module" - should therefore be enough!!
In R2 I am only using 'FUNC. In R3 I probably would use the so called 'MODULE only.
The rest of above mentioned possibilities should be history and only be kept for downward compatibility. Esp. for beginners things would become much easier!
As somehow special cases remain interfaces to other languages like C, to DLLs and - last, not least! - to/from applications written e.g. for windows. 'CALL is available and working but not even mentioned in R2 function summary! I am missing the other way round: from windows to REBOL.
If the "dialog" between different applications could be improved this would be fine! Don't know wether we really need the shells for that. OS-extensions to call REBOL from windows/Linux etc. surely is for most users more important than extensions to any internet browsers.
Keep it easy. Small is beautiful! ;-)
Hopefully I am not on a totally wrong path with my ideas.
So far I've been unsuccessful loading *any* dll. I change-dir into the directory of the DLL and type 'import %blah.dll' and get back "** access error: cannot open: %blah.dll reason: none"
Any ideas/pointers ?
Post a Comment:
You can post a comment here. Keep it on-topic.