[REBOL] Re: objects without overhead
From: ole_f:post3:tele:dk at: 22-Oct-2000 23:58
m>
Message-ID: <[22-Oct-0014381164ole_f--post3--tele--dk]>
MIME-Version: 1.0
X-Mailer: NewsWise ALPHA 0.3 by Leon Woestenberg & Ole Friis
Organization: ATO - Amiga Translators' Organization
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-Wordwrap: 78
Hi Rodney, 19-Oct-2000 you wrote:
^^^^^^
Ah, at last: A list server which supports names in e-mail messages. That's a
feature I've really missed while the list has been running on Selma (hint)
;-)
>I believe you are thinking the same way I did which is incorrect.
>The functions are duplicated as evidenced by a response that Elan
>sent about this very question a few weeks back. Here it is:
(Sorry if I've missed some messages from time to time, but I just don't have
the time to read carefully through them all. So thanks for quoting Elan!!!)
OK, Elan _may_ be right, but look below.
[...]
>I believe REBOL makes a new copy of functions for each derived object.
[...]
>Let us replace the string "a" by the string "b" in p's function f
[...]
>Were we successful?
[...]
>Yes. Was the function f in the parent object o also modified?
[...]
>No!
>Apparently modifications to the inherited function f in p do not propagate
>to the f function in the parent object o, ergo the two functions are
>independent of each other.
So that's what the REBOL semantics apparently define. However, if the
_implementation_ of REBOL is clever, those two functions will refer to the
same function until you start modifying one of them. Then REBOL will split
them into two, and modify one of them.
This is, AFAIR, called "copy-on-write" and is also used in NewtonScript, the
script language that accompanied the Newton message pad from Apple. This
scripting language implementation had lots of available ROM, but not much
RAM, so "copy-on-write" saved lots of RAM this way (and used some ROM because
of the added complexity of the interpreter code). (BTW, NewtonScript is
prototype-based, just like REBOL.)
However, I wasn't aware that REBOL behaves the way that Elan describes, and
the above is only guesswork. Plus, the following REBOL session also indicates
that Elan may be totally right:
>> a: make object! [t: "aaa"]
>> b: make a []
>> c: make a []
>> b/t =? c/t
== false
In this session, I haven't altered a/t at all, so if the REBOL implementation
used simple "copy-on-write", the last expression should have evaluated to
true. Of course, it is possible to implement the above with "copy-on-write"
too, but I just have a feeling that REBOL Tech. haven't.
So, let's have a word from REBOL Tech.:
- Why was REBOL designed this way (as I don't see any benefits of doing it
that way, as I don't see memory overhead as a benefit)
- _Does_ the REBOL interpreter actually use "copy-on-write", or should we get
used to writing object-oriented REBOL programs in obscure ways to avoid
memory and speed penalties (the latter because the values in the prototype
object has to be copied somehow, and this takes time)?
The above two questions are intentionally written in a provocative way to,
well, provoke REBOL Tech. to answer them :-)
>Rodney
Kind regards,
--
Ole
