At a CLASS crossroads?

Carl Sassenrath, CTO
REBOL Technologies
16-Aug-2006 21:41 GMT

Article #0035
Main page || Index || Prior Article [0034] || Next Article [0036] || 27 Comments || Send feedback

[For REBOL Experts Only]

As you know, REBOL is a prototype-based object language. The idea of prototype objects came to REBOL early in its development from the language Self (Ungar and Smith). (See Wikipedia: Prototype Based Languages)

REBOL is prototype-based because a defining principle of REBOL is that simple things must be simple. Protypes provide a quick and informal definition of objects. You can create a new object as simply as this:

obj1: make object! [name: "Bob" age: 27 city: "Ukiah"]

You can now make additional instances with:

obj2: make obj1 [name: "Ann"] ; (other values inherited)

So that's handy and nice, and it will remain a primary method for REBOL 3.0.

However, in REBOL 3.0, we have reached the crossroads because we will support a more formal definition of objects. For instance, if you want private fields, typed instance variables, embedded documentation, an intializer function, and other properties, you can specify them.

Of course, it is possible to make these features "live" within the existing prototype-based model of objects. The question is, are we really implementing a hidden class-based system as a by-product?

I ask this question of myself, daily. The enhancements seem class-based because the definitional part of an object spans all instances (by reference back to the definition). In addition, that definition is immutable (cannot be modified by the instances without creating a new definition itself).

Other factors become important as well. For instance, if you mold an object, do you get its definition block molded for all instances? If we allowed classes, would there be a way to mold an instance and refer to its class (and that's problematic because REBOL does not support such reverse value-to-word mappings, so a new namespace may be required for class names - violating one of the denotational semantic rule at the foundation of REBOL).

And, on top of all this, I've yet to mention the fact that REBOL 3.0 is likely to support object methods to make object function implementation more efficient (in memory usage). The implementing of methods in REBOL has always been considered difficult (mainly because there is no referential anchor for a group, a class, of objects -- they are prototypical and can be cloned from each other, not just a single parent). A class-based approach makes the implementation of methods much easier.

So, think about that a bit. You should know that the extensions to objects are critical to 3.0 because we need features like typed instance variables to implement ports, events, gobs, and other C-interfaceable structures.

Watch Out for the Cliff:

Due to REBOL's different/advanced semantics, this whole topic of objects and classes can get really deep, really fast.

In the early days, the team had many discussions that lasted for periods of months-on-end about how to deal best with the semantics of objects. (In the denotational semantics of functional languages the concept of objects is pretty much a nightmare.)

What we learned long ago is that we must be very pragmatic about the solution, because there can be no pretty and pure mathematic solution. And, we certainly do not want to delay the 3.0 release.

So, consider this issue in a practical realm and at not too great a depth. Otherwise, it might indeed lead to your eventual insanity, as it has certainly taken its toll on mine over the years.


Updated 21-Mar-2017 - Edit - Copyright REBOL Technologies -