[REBOL] rebol weak points (i think) Re:(3)
From: joel:neely:fedex at: 10-Sep-2000 23:27
Hi, Rishi...
Just a couple of points re REBOL objects that may be of some help:
[rishi--picostar--com] wrote:
> no. The Math/Pie you have created is an instance variable not a
> static variable. It is associated with an instance of the class,
> not the class itself. A static variable means that there is a
> single copy of this variable associated with class itself. You do
> not need to instantiate a class to use static variable...
>
1) The distinction to which you keep referring -- "class variable"
vs. "instance variable" -- doesn't exist at all in REBOL because
REBOL doesn't use the class-based object model of Java or Smalltalk.
There are other ways to think of objects than simply as instances of
classes
. In NewtonScript and Self, for example, objects exist
completely as standalone entities without any enveloping class.
Instead, in both of those langauges, objects can have "prototypes",
other objects to which they refer for common (or default) attributes
and methods. In those languages, the object-to-prototype relationship
is maintained throughout the lifetime of an object, so that changes
to an attribute/method of an object are visible within any other
objects that refer to the first object as their prototype (and that
have not overridden the attribute/method involved).
In REBOL, an object is a standalone entity. It may be created
directly, using make object! ... or may be created using another
object as a model or specification. However, it is cloned at the
time of creation, and no longer maintains a relation to its model
object. For example:
>> ob1: make object! [
[ attr: 23
[ meth: func [] [print attr: attr + 1]
[ ]
>> kenobi: make ob1 []
>> ob1/meth
24
>> ob1/meth
25
>> ob1/meth
26
>> kenobi/meth
24
>> kenobi/meth
25
>> kenobi/meth
26
>> ob1/attr: 2
== 2
>> ob1/meth
3
>> ob1/meth
4
>> kenobi/meth
27
>> kenobi/meth
28
>>
Notice that kenobi has its own copy of attr and meth which
are independent of those in ob1 even though no explicit overriding
was done at the creation of kenobi . Therefore all objects are
created equal, without any "class" vs. "instance" distinction.
Therefore the term "static" as used in Java or c++ is meaningless
in REBOL.
> The main advantage of having static variables would be to prevent
> name collisions and to group variables/functions that act on a
> class (not an object) together for use in a more natural way.
>
> The main disadvantage of having static variables is that perhaps
> it is an unnecessary complication. But I don't think so. Maybe
> because I come from java/javascript background. I'm still wondering
> though if there is a way to have static variables that I don't know.
>
> Regardless, the main problem that I wonder about is if rebol is
> suited for modular programming where people reuse other people's
> functions/code. Since everything is either global or local, it seems
> as though it would be unnatural to use rebol in this way...
>
2) I frequently use objects in my own REBOL programming to get
exactly the benefit you're looking for: to partition the namespace.
Most of my REBOL source files define objects to encapsulate all of the
variables, subordinate functions, parse pattern blocks, etc. that make
up the details of the main idea of the script. A limited number (often
only one!) of the functions within the object are actually intended for
use by the clients of the object. It's a handy way to structure and
modularize libraries of code (and DOES offer a alternative to global
and local). I write code in this fashion when I want to reuse it
myself across many independent projects.
Hope this helps!
-jn-
