Bye bye System object?

Well... if all of this REBOL 3.0 discussion has not got you thinking, here's something that will...

I think I've hinted at it before: The system object is problematic because it allows an implicit sharing model. (I've known that since I introduced it, and I knew a day would come when it had to be changed.)

The Problem:

The system object allows access to most of REBOL's internal state information. This information is often returned in the form of objects. Within a modular and multitasked system, such objects are problematic.

There are two main issues:

Many of these objects will become independent modules. For example, the View environment will become a module of REBOL, exporting the necessary functions to your program. (Don't worry, you can still get to the View module and its code/data, but such access is done in a more specific manner.)
If you are going to share objects between modules and tasks, what happens if one module/task modifies the object? Will it be "surpise!" in other modules? This can also become a security hole.

The Solution:

We will need to either remove the system object, or at the very least, change the way the system object works and what it contains.

Let's look closer. If you type help system you get this list:

version         tuple!    1.3.2.3.1
build           date!     5-Dec-2005/18:22:54-8:00
product         word!     View
core            tuple!    2.6.3
components      block!    length: 54
words           object!   [unset! error! datatype! context! native! action! ...
license         string!   {REBOL End User License Agreement IMPORTANT. READ ...
options         object!   [home script path boot args do-arg link-url server...
user            object!   [name email home words]
script          object!   [title header parent path args words]
console         object!   [history keys prompt result escape busy tab-size b...
ports           object!   [input output echo system serial wait-list]
network         object!   [host host-address]
schemes         object!   [default Finger Whois Daytime SMTP ESMTP POP IMAP ...
error           object!   [throw note syntax script math access command resv...
standard        object!   [script port port-flags email face sound]
view            object!   [screen-face focal-face caret highlight-start high...
stats           native!   System statistics. Default is to return total memo...
locale          object!   [months days]
user-license    object!   [name email id message]

You can break this list into different solution categories:

	Locked	Some of these fields are not a problem because we can lock their modification. For example, programs should not be allowed to modify the `version` field. Many others fall into this category.
	Local	Some fields could be "context relative". For example, your script module (the "global environment of your script") could have access to the `system/script` object, but other modules may not.
	Replaced	Some fields such as `schemes` and `view` are replaced with modules. I'm not yet sure if these fields will have meaning here.
	Removed	For example, the `words` object is gone. There is no global list of words and values. Words are relative to their modules. (But, it may be possible for the word list to contain the words and values of the current module, so perhaps this could be merged with the local category above.)

System as a Function?

One solution might be to make system a function, not an object. This could be made to work for a lot of accesses:

print system/version

The advantage being that the system function could dynamically create the necessary values as needed.

But, this functional approach would break scripts that set specific values directly, such as:

system/options/binary-base: 64

(Although, that does get you thinking that such a function set-path notation may have merit for functions. But, let's not get distracted right now.)

So, there's something for you to think about. This issue is not currently urgent, but it will need to be resolved in the weeks ahead.

7 Comments