Comments on: 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:

1. 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.)

2. 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:

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

Comments:

Brian Hawley 4-May-2006 15:08	First of all, let me say: It's about time! I love that you are revisiting this design choice. However much code that will require changing, I will welcome those changes (I didn't like that code anyways, particularly that binary-base). Now given that, I think you should replace the system object with not one function, but at least two: SYSTEM (assign it to REBOL too) and SCRIPT. This way you could keep the settings logically seperate. Either that or have system/script return an object chain created when necessary and assign that object. Also, consider that some of these settings may be even more fine-grained than the script level, even thread-local, and many of these settings should have global defaults and local current settings as well. As it is you may still have problems with the fields like script/parent that chain along, as you can't easily do that chaining with function returns. Plus, this sounds like you may need those set-functions a lot, plus the ability to assign a get-function to the same field. This sounds really cool!
Brian Hawley 4-May-2006 15:14	I, for one, will not mourn the loss of the words object if it is replaced by something better. As a storage place for symbols its limits were annoying - newLISP uses a btree for its symbols and thus can handle millions of them at a time. As a way to access global words, those global words are a little disturbing anyways, especially since they can't currently be made readonly. Good riddance.
Volker 4-May-2006 15:59	Multitasking - then access should be bya dialect, to query multiple values at once? Also about dropping global - please keep the console in mind! I hope testing things stays as comfortable as it is now :)
Brian Hawley 4-May-2006 17:18	I would rather the console be a local environment that has words from other modules imported. You would be able to redefine words but your redefinitions would be local to the console environment. You could then work or test from there, and collect your changes in other modules for reuse later.
maarten 4-May-2006 18:16	As far as I'm concerned: remove it. Inever liked that I had to navigate and change things in One Global Object. What would be nice is a way to add module settings in a consistent way; the remains of the current system object would simply be the module settings for the module 'built-in
maximo 5-May-2006 13:21	I very much like brian's idea about chaining such values. But there still must be one place to make global things accessible from any code. if only to make module, script and passed object interdependencies easy to manage. for example, if the user of rebol changes the load function in order to add security to it... view's usage of load must not become independent from the global definition, otherwise, such fixes are practically useless.
Scot 25-Sep-2006 19:02:35	Function with or without chaining values.

Post a Comment:

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