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.

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.