Thanks Joel! That was great help. I'm surprised I didn't think of using objects in
that way. Rebol
is more powerful everytime I look at it ...Simple but Powerful... And that modular
architecture
paper I just read (thanks Andrew...) sounds really interesting! I definately think
I've found the
language I've been searching for...
Sorry about the html messages i've been sending to this list. My beos networking is
down for some
reason and I am stuck in complicated microsoft outlook program. Look forward to
switching to qnx
realtime platform soon!!
By the way, did anyone write a rebapp to read/post messages on this newsgroups rather
than having it
come in my mail box? I am having to constantly subscribe/unsubscribe on demand
depending on when I
need to send messages. If their is such a rebapp, please let me know! (or do I have to
write it?)
And is there a way to read older archives of this newsgroup (like several months/years
old) so I
don't have to post questions that have been answered?
Rishi
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, September 10, 2000 9:27 PM
Subject: [REBOL] rebol weak points (i think) Re:(3)
> Hi, Rishi...
>
> Just a couple of points re REBOL objects that may be of some help:
>
> [EMAIL PROTECTED] 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-
>
